On 29-Jul-05, 08:50 (CDT), GOMBAS Gabor <[EMAIL PROTECTED]> wrote:
> On Thu, Jul 28, 2005 at 08:38:17AM -0500, Steve Greenland wrote:
> Exercise: let's say I have an application that uses GSSAPI, and has to
> be able to be built statically. Requirements:
>
> - It should build with Heimdal's libgs
On Thu, Jul 28, 2005 at 02:18:29PM -0400, Jay Berkenbilt wrote:
> > FWIW, detecting a fixed libtool would be rather difficult, since it's the
> > libtool used by the depending application which does the recursion and
> > therefore needs to be fixed.
> I was thinking we'd be able to tell from the .
> "Steve" == Steve Greenland <[EMAIL PROTECTED]> writes:
>> fact 3: libtool library libtool tries to implement a wrapper
>> around shared library and static library, so that both of them
>> can be uniformly processed, and allows specifying just: libtool
>> cc -lnewt a.c
St
On Fri, Jul 29, 2005 at 12:06:38PM -0400, Jay Berkenbilt wrote:
> This is nice, but I think it's not really very autoconfish [tm] in
> spirit.
It is not meant to be autoconfish. It is meant to be run _before_
configure, so you can decide if you have to re-libtoolize the package or
not.
> Also, t
GOMBAS Gabor <[EMAIL PROTECTED]> wrote:
> On Thu, Jul 28, 2005 at 08:57:29AM -0400, Stephen Frost wrote:
>
>> I'd think we could come up with a way to detect the version of libtool
>> in use, somehow. :)
>
> LTMAIN_SH_PATH=`autoconf --trace='AC_CONFIG_AUX_DIR:$1'`
> LTMAIN_SH_PATH="${LTMAIN_SH_PAT
On Thu, Jul 28, 2005 at 08:57:29AM -0400, Stephen Frost wrote:
> I'd think we could come up with a way to detect the version of libtool
> in use, somehow. :)
LTMAIN_SH_PATH=`autoconf --trace='AC_CONFIG_AUX_DIR:$1'`
LTMAIN_SH_PATH="${LTMAIN_SH_PATH:-.}"
grep ^VERSION "$LTMAIN_SH_PATH"/ltmain.sh |
On Thu, Jul 28, 2005 at 07:05:34AM -0400, Stephen Frost wrote:
> We've had that discussion before. Last I recall there wasn't really a
> huge fight to keep them.
Well, Debian developers do not really need them. But there are people
who do not develop Debian but develop other software _using_ Deb
On Thu, Jul 28, 2005 at 08:38:17AM -0500, Steve Greenland wrote:
> Why is this better? I have to change my perfectly normal, standard Unix
> link command to use something that completely hides the actual link
> command and makes debugging problems nearly impossible?
Exercise: let's say I have an
Steve Langasek <[EMAIL PROTECTED]> writes:
> I think static libs have outlived their usefulness in Debian for the
> most part; but using this to justify creating whole *new* packages for
> static linking would just be insane. The dependencies of -dev packages
> are just not that big a deal to war
On Fri, Jul 29, 2005 at 07:06:34AM +0900, Junichi Uekawa wrote:
> > > - Don't ship .la files in the -dev package; don't depend on any other -dev
> > > packages except those whose headers you need. This gives optimal
> > > results
> > > for shared linking by pruning all unnecessary build-depen
Hi,
> > - Don't ship .la files in the -dev package; don't depend on any other -dev
> > packages except those whose headers you need. This gives optimal results
> > for shared linking by pruning all unnecessary build-dependencies and
> > dependencies; but it also screws over anyone trying to
Steve Langasek <[EMAIL PROTECTED]> wrote:
> It doesn't exist; I think it's a great idea. Perhaps a tool named
> dh_libtool, which populates a substvar named ${libtool:Depends}?
Sounds good to me.
I'm going to be leaving my current job in a few weeks and taking
several weeks off between jobs. I
On 28-Jul-05, 03:02 (CDT), Junichi Uekawa <[EMAIL PROTECTED]> wrote:
> fact 1: shared library
>
> gcc -lnewt a.c
Right. No problem.
> fact 2: static library
>
> gcc -lslang -lnewt a.c
Right, Just like it's always been on Unix systems.
> fact 3: libtool library
> libtool tries to impleme
* Steve Langasek ([EMAIL PROTECTED]) wrote:
> It doesn't exist; I think it's a great idea. Perhaps a tool named
> dh_libtool, which populates a substvar named ${libtool:Depends}?
This sounds reasonable to me; I appriciate that it's a libtool-specific
thing and not a blanket policy. :)
> FWIW, de
On Thu, Jul 28, 2005 at 08:29:52AM -0400, Jay Berkenbilt wrote:
> Steve Langasek <[EMAIL PROTECTED]> wrote:
> > - Leave the .la files in place; -dev packages need to depend on -dev
> > packages corresponding to those runtime dependencies that are also built
> > using libtool. This is the stat
Steve Langasek <[EMAIL PROTECTED]> wrote:
> - Leave the .la files in place; -dev packages need to depend on -dev
> packages corresponding to those runtime dependencies that are also built
> using libtool. This is the status quo.
If we do this (which I think we should for now), I would sugges
* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
> > - Option 4 (requires volunteers): fix libtool
>
> Blankly stating that libtool needs to be 'fixed'
> because it is 'broken' is not very helpful.
> Would you care to explain what needs to be fixed and why
> it is broken? Good working examples would
* Steve Langasek ([EMAIL PROTECTED]) wrote:
> On Wed, Jul 27, 2005 at 08:57:51PM -0400, Stephen Frost wrote:
> > * Steve Langasek ([EMAIL PROTECTED]) wrote:
> > > On Wed, Jul 27, 2005 at 07:20:44PM -0400, Stephen Frost wrote:
> > > > libtool is broken in this regard and needs to be fixed to survive
Hi,
> > - Kill the .la files and .a files. Drop support for static linking. Not
> > something that should be done lightly and without prior project-wide
> > discussion.
> > - Leave the .la files in place; -dev packages need to depend on -dev
> > packages corresponding to those runtime depe
On Wed, Jul 27, 2005 at 10:16:54PM -0400, Josh Metzler wrote:
> On Wednesday 27 July 2005 10:10 pm, Steve Langasek wrote:
> > But ok, yes, that is an option; let's spell the options out completely:
> >
> > - Don't ship .la files in the -dev package; don't depend on any other
> > -dev packages excep
On Wednesday 27 July 2005 10:10 pm, Steve Langasek wrote:
> But ok, yes, that is an option; let's spell the options out completely:
>
> - Don't ship .la files in the -dev package; don't depend on any other
> -dev packages except those whose headers you need. This gives optimal
> results for shared
On Wed, Jul 27, 2005 at 08:57:51PM -0400, Stephen Frost wrote:
> * Steve Langasek ([EMAIL PROTECTED]) wrote:
> > On Wed, Jul 27, 2005 at 07:20:44PM -0400, Stephen Frost wrote:
> > > libtool is broken in this regard and needs to be fixed to survive
> > > missing files.
> > Then fix it instead of gi
* Steve Langasek ([EMAIL PROTECTED]) wrote:
> On Wed, Jul 27, 2005 at 07:20:44PM -0400, Stephen Frost wrote:
> > libtool is broken in this regard and needs to be fixed to survive
> > missing files.
>
> Then fix it instead of giving people bad advice.
Do you actually have anything beyond "libtool
On Wed, Jul 27, 2005 at 07:20:44PM -0400, Stephen Frost wrote:
> > 4. -dev packages should depend on other -dev packages?
> > Yes.
> Whoah, whoah, whoah. This is just blatently false. There *certainly*
> wasn't a consensus that -dev packages should regularly depend on -dev
> pacakges. There'
* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
> 1. Conclusion:
> For the initial question of
> 'How does one decide which -dev package accompanies
> runtime library package'
> There is no answer, and we have not reached the consensus.
It would be possible to put forth a proposal to deal with
Hi,
Since I've started up this thread, I'd like to summarize what was
discussed in this thread.
1. Conclusion:
For the initial question of
'How does one decide which -dev package accompanies
runtime library package'
There is no answer, and we have not reached the consensus.
2. Methods to
Junichi Uekawa <[EMAIL PROTECTED]> wrote:
> > > 2. The information of -dev packages depending on other -dev packages
> > > cannot be automatically determined currently;
> > > it should be possible to obtain a minimal list by analyzing the
> > > NEEDED field of the objdump output.
> >
> > Errr, -
On 7/15/05, Steve Langasek <[EMAIL PROTECTED]> wrote:
> On Fri, Jul 15, 2005 at 05:30:44PM +0900, Junichi Uekawa wrote:
> > An alternate solution is to have a database for that kind of thing,
> > but I forsee that it requires effort to maintain and keep up-to-date.
>
> Like the database I just que
On Fri, Jul 15, 2005 at 05:30:44PM +0900, Junichi Uekawa wrote:
> > > Having a solid naming scheme will allow me to
> > > ldd /usr/lib/libwhatever.so to track down its
> > > shared library dependency, and appending "-dev"
> > > to individual package to create the list of
> > > requisite -dev pac
On Fri, Jul 15, 2005 at 05:18:23PM +0900, Junichi Uekawa wrote:
> > > BTW, having Build-Depends: libfoo-dev in
> > > a library's build-deps, will allow the developer
> > > to overlook a soname change in depending shared library.
> > > Which is a bad idea in the QA standpoint.
> > Yes and no.
> >
> Stephen's points are valid and quite useful
> considering an upstream developer's point of view,
> but for random user joe who is trying to find a development
> package, one of the following may help him find the right package
Joe user should do:
apt-cache search libNAME dev
(or use synaptic,
On Fri, Jul 15, 2005 at 10:44:04PM +0900, Junichi Uekawa wrote:
> Stephen's points are valid and quite useful
> considering an upstream developer's point of view,
> but for random user joe who is trying to find a development
> package, one of the following may help him find the right package
>
>
Hi,
Thanks for your time and feedback. I appreciate it very much.
> You could also suggest a policy for libs to have a libfoo.devname file
> similar to the libfoo.shlibs file but naming the needed -dev
> packages. If that is a good idea or not you have to think about. Just
> a wild idea.
Yes, t
Junichi Uekawa <[EMAIL PROTECTED]> writes:
> Hi,
>
>> > Having a solid naming scheme will allow me to
>> >
>> > ldd /usr/lib/libwhatever.so to track down its
>> > shared library dependency, and appending "-dev"
>> > to individual package to create the list of
>> > requisite -dev packages.
You c
Junichi Uekawa <[EMAIL PROTECTED]> writes:
> Hi,
>
>> > BTW, having Build-Depends: libfoo-dev in
>> > a library's build-deps, will allow the developer
>> > to overlook a soname change in depending shared library.
>> > Which is a bad idea in the QA standpoint.
>>
>> Yes and no.
>>
>> The program
* Francesco P. Lovergine ([EMAIL PROTECTED]) wrote:
> On Fri, Jul 15, 2005 at 09:36:47AM +0300, martin f krafft wrote:
> > also sprach Junichi Uekawa <[EMAIL PROTECTED]> [2005.07.14.1416 +0300]:
> > > libfoobar-2.1-0 will have
> > > libfoobar-2.1-0-dev.
> >
> > Please distinguish between API and
* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
> > If this is actually necessary for libtool-using packages, then write
> > something which goes through all of the .la files and does this, since
> > that's what libtool wants to do.
>
> and
>
> > Errr, you still havn't said what problem you're tryin
* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
> > > BTW, having Build-Depends: libfoo-dev in
> > > a library's build-deps, will allow the developer
> > > to overlook a soname change in depending shared library.
> > > Which is a bad idea in the QA standpoint.
> >
> > Yes and no.
> >
> > The program
On Fri, Jul 15, 2005 at 09:36:47AM +0300, martin f krafft wrote:
> also sprach Junichi Uekawa <[EMAIL PROTECTED]> [2005.07.14.1416 +0300]:
> > libfoobar-2.1-0 will have
> > libfoobar-2.1-0-dev.
>
> Please distinguish between API and ABI!
>
True. Indeed the proposed policy is already followed in
Hi,
> > Having a solid naming scheme will allow me to
> >
> > ldd /usr/lib/libwhatever.so to track down its
> > shared library dependency, and appending "-dev"
> > to individual package to create the list of
> > requisite -dev packages.
>
> With the current scheme it is:
>
> ldd /usr/lib/libwh
Hi,
Thanks for your input.
> > Having a solid naming scheme will allow me to
> >
> > ldd /usr/lib/libwhatever.so to track down its
> > shared library dependency, and appending "-dev"
> > to individual package to create the list of
> > requisite -dev packages.
>
> If this is actually necessa
Hi,
> > BTW, having Build-Depends: libfoo-dev in
> > a library's build-deps, will allow the developer
> > to overlook a soname change in depending shared library.
> > Which is a bad idea in the QA standpoint.
>
> Yes and no.
>
> The programer can overlook the soname change for the source. The A
also sprach Junichi Uekawa <[EMAIL PROTECTED]> [2005.07.14.1416 +0300]:
> libfoobar-2.1-0 will have
> libfoobar-2.1-0-dev.
Please distinguish between API and ABI!
--
Please do not send copies of list mail to me; I read the list!
.''`. martin f. krafft <[EMAIL PROTECTED]>
: :' :proud
Junichi Uekawa <[EMAIL PROTECTED]> writes:
> BTW, having Build-Depends: libfoo-dev in
> a library's build-deps, will allow the developer
> to overlook a soname change in depending shared library.
> Which is a bad idea in the QA standpoint.
Yes and no.
The programer can overlook the soname chang
Junichi Uekawa <[EMAIL PROTECTED]> writes:
> Having a solid naming scheme will allow me to
>
> ldd /usr/lib/libwhatever.so to track down its
> shared library dependency, and appending "-dev"
> to individual package to create the list of
> requisite -dev packages.
With the current scheme it is:
Will Newton <[EMAIL PROTECTED]> writes:
> On Thursday 14 July 2005 17:14, Junichi Uekawa wrote:
>
>> The current recommendation I'm trying to give is:
>>
>> Package: libXXX-dev
>> Conflicts: libXXX-dev
>> Provides: libXXX-dev
>>
>>
>> Thus, it won't contradict with your requirement to
>> be ab
#include
* Will Newton [Thu, Jul 14 2005, 05:36:05PM]:
> > Thus, it won't contradict with your requirement to
> > be able to just build-depend on libXXX-dev.
>
> I may be wrong, but I thought it was incorrect to build-dep only on a pure
> virtual package? e.g.:
>
> Build-Depend: xlibmesa-gl-de
* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
> The current recommendation I'm trying to give is:
>
> Package: libXXX-dev
> Conflicts: libXXX-dev
> Provides: libXXX-dev
>
>
> Thus, it won't contradict with your requirement to
> be able to just build-depend on libXXX-dev.
Uhh, then it doesn't
* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
> BTW, having Build-Depends: libfoo-dev in
> a library's build-deps, will allow the developer
> to overlook a soname change in depending shared library.
> Which is a bad idea in the QA standpoint.
Uh, no it isn't. SONAME changes are fine, the package h
* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
> > > There may be other showstoppers.
> >
> > What does doing this solve? What does it even help with?
>
> Hmmm... we are talking about naming
> Debian development shareed library package names based on
> Debian runtime shared library package names.
Hi,
> You can (and it is often done) extend an api to include more
> functionality without breaking the existing api. Any program using one
> of the new functions must use a versioned depend on the libfoo-dev
> package introducing the function.
>
> The API can (and will) even stay compatibly acro
On Thursday 14 July 2005 17:14, Junichi Uekawa wrote:
> The current recommendation I'm trying to give is:
>
> Package: libXXX-dev
> Conflicts: libXXX-dev
> Provides: libXXX-dev
>
>
> Thus, it won't contradict with your requirement to
> be able to just build-depend on libXXX-dev.
I may be wron
Hi,
> > 2. The information of -dev packages depending on other -dev packages
> > cannot be automatically determined currently;
> > it should be possible to obtain a minimal list by analyzing the
> > NEEDED field of the objdump output.
>
> Errr, -dev packages generally don't (and shouldn't) depe
Hi,
> > I'd like to propose, for new -dev packages, to
> > name -dev packages after their runtime library counterparts.
>
> I personally found it very handy that the dev packages automatically
> selects the most recent API compatible version. Why do you want this
> switch by the way? You did not
Hi,
> > There may be other showstoppers.
>
> What does doing this solve? What does it even help with?
Hmmm... we are talking about naming
Debian development shareed library package names based on
Debian runtime shared library package names.
>
> > I would really like this 10-year old non-reg
[once more, doesn't belong on -release...]
On Thu, Jul 14, 2005 at 12:11:21PM -0400, Stephen Frost wrote:
> * Junichi Uekawa ([EMAIL PROTECTED]) wrote:
> > > * Junichi Uekawa ([EMAIL PROTECTED]) wrote:
> > > > I'd like to propose, for new -dev packages, to
> > > > name -dev packages after their r
Junichi Uekawa <[EMAIL PROTECTED]> writes:
> Hi,
>
>> > I'd like to propose, for new -dev packages, to
>> > name -dev packages after their runtime library counterparts.
>> >
>> > If the library package is named lib$NAME,
>> > call the -dev package lib$NAME-dev.
>> [...]
>>
>> Hej,
>> The obvio
* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
> > * Junichi Uekawa ([EMAIL PROTECTED]) wrote:
> > > I'd like to propose, for new -dev packages, to
> > > name -dev packages after their runtime library counterparts.
> >
> > Uh, no? The -dev packages have no need to match to a specific runtime
> > li
* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
> There may be other showstoppers.
What does doing this solve? What does it even help with?
> I would really like this 10-year old non-regulation to
> go to a concensus (it is indeed rather embarassing we don't
> agree on a good solution after 10 yea
Hi,
> * Junichi Uekawa ([EMAIL PROTECTED]) wrote:
> > I'd like to propose, for new -dev packages, to
> > name -dev packages after their runtime library counterparts.
>
> Uh, no? The -dev packages have no need to match to a specific runtime
> library and this just creates unnecessary work.
Well
Hi,
> > I'd like to propose, for new -dev packages, to
> > name -dev packages after their runtime library counterparts.
> >
> > If the library package is named lib$NAME,
> > call the -dev package lib$NAME-dev.
> [...]
>
> Hej,
> The obvious downside of this is that the name of dev-package will
On Thu, 2005-07-14 at 20:16 +0900, Junichi Uekawa wrote:
> I'd like to propose, for new -dev packages, to
> name -dev packages after their runtime library counterparts.
I personally found it very handy that the dev packages automatically
selects the most recent API compatible version. Why do you
* Junichi Uekawa ([EMAIL PROTECTED]) wrote:
> I'd like to propose, for new -dev packages, to
> name -dev packages after their runtime library counterparts.
Uh, no? The -dev packages have no need to match to a specific runtime
library and this just creates unnecessary work.
> This allows mechani
[I am stopping the cross-posting to -release, as -release is no
discussion list]
On 2005-07-14 Junichi Uekawa <[EMAIL PROTECTED]> wrote:
> I'd like to propose, for new -dev packages, to
> name -dev packages after their runtime library counterparts.
>
> If the library package is named lib$NAME,
>
64 matches
Mail list logo
