[gentoo-dev] .la files and their future on Gentoo

[gentoo-dev] .la files and their future on Gentoo

[Jorge Manuel B. S. Vicetto]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello.

Given the recent activity around .la files and conflict about how to
deal with them, I propose we discuss this issue in this mailing list,
and take this issue to the council.
That way, we can make a global decision, taking into account all the
arguments for and against, find a balance, opt for a policy, inform
users and developers about it and move on.

With that goal in mind, I'd like to ask anyone with arguments about this
issue to present them as a reply to this thread.
I'll present some arguments and some of the issues being raised on a
latter mail.

- -- 
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJMp438AAoJEC8ZTXQF1qEPGzkQAMGg9x20PtHZ3KOlWwMwBf68
/mPUjmHYMFJmh/TVJniBdF7GWB4U+2pFmRYrbGixfglmSNtT6aohycFmvcZdrGmY
GUZUbZnl4FvXnVp+XAYxu21Zzy/+NxwDiZchBXXjL6lLAWUnPiP0nEwNkB5yTOZS
IPirLQ9wIqT2tb1KS1JNvas858qHAFJUt8yDd5Iv58rqDyPsLHrhJM8fdohMn3R0
8+aV9U4M3OpXpS0F53heJr3dYQB9Onw8HwUmQ1dcxfBtda7V29kQC24Eyr62LVcP
Ajpjp0DroYOUTSaz2tOkReILDPOr3XFxCFdNYKtq9wh+Pq2fqdi0hZl/cfgTWFGW
0938sE/HA5rqnyHiSqqpYndywrH8YCUMovwti5/NSOSrGzaC7Jia5QpTpWZi8KJ4
FP7vtdG7BdKGEb2mQiDOQ7AHP6J8qWa6adpMAShjDndLwqftuRi9eRWL5WqVFqq3
25RgTCaRXPrzJYdJ35pirjK7ZrXx4M8KQ3Jd4Ljq7FTCB11V8J35itrC9hTKdLSI
3U8LrwDju9U1KixBvAdsxjHfolSjmaKGj+t1dcBocVjHFD2dBPSZf5JVwnNgNTcu
r8G5799k6VFkWIdOoIylg8HUuHs5SlmSn9EZmiaSP/atwEAQDzhy1Nbj7b0qnPRY
pbbu82EiSwyZHwpDRcpS
=MFGl
-----END PGP SIGNATURE-----

Re: [gentoo-dev] .la files and their future on Gentoo

[Rémi Cardona]

Le 02/10/2010 21:54, Jorge Manuel B. S. Vicetto a écrit :
> With that goal in mind, I'd like to ask anyone with arguments about this
> issue to present them as a reply to this thread.

[putting on my X11 cap]

As far as X11 packages are concerned (libX11, libXext, cairo, etc), we
can remove .la files now since upstream only supports linking through
pkg-config (static linking included).

So X11 can remove them any time, I was just waiting for a flag-day to do it.

Cheers,

Rémi

Re: [gentoo-dev] .la files and their future on Gentoo

[David Leverton]

On 2 October 2010 20:54, Jorge Manuel B. S. Vicetto
<jmbsvicetto@gentoo.org> wrote:
> Given the recent activity around .la files and conflict about how to
> deal with them, I propose we discuss this issue in this mailing list,
> and take this issue to the council.
> That way, we can make a global decision, taking into account all the
> arguments for and against, find a balance, opt for a policy, inform
> users and developers about it and move on.

While I do agree that the underlying problem we're trying to solve is
worth solving, I do have a couple of small concerns about how it's
being done.  The first is that it seems people are judging whether a
particular .la file is "needed" by checking whether anything currently
in the tree needs it, but this doesn't take into account anything that
/isn't/ in the tree yet.  The second is that removing .la files
everywhere makes it hard for people to experiment with alternative
solutions, as testing an alternative would require modifying all the
affected ebuilds to stop removing them.  (And yes, I am interested in
doing so myself, although time constraints mean it might not
happening.)

Would it be too much trouble to have a standardised variable that
means .la files should be kept?  It maybe /shouldn't/ be exposed as a
USE flag because very few people will need it, but if it's easy to
implement (maybe by having an eutils function to do the removal,
checking the variable first) it would remove any objections I could
imagine.

As I said, these are minor points, and I wouldn't expect people to go
to great effort to satisfy them.  Just something to consider.

Re: [gentoo-dev] .la files and their future on Gentoo

[Richard Freeman]

On 10/03/2010 07:53 AM, David Leverton wrote:
> Would it be too much trouble to have a standardised variable that
> means .la files should be kept?  It maybe /shouldn't/ be exposed as a
> USE flag because very few people will need it, but if it's easy to
> implement (maybe by having an eutils function to do the removal,
> checking the variable first) it would remove any objections I could
> imagine.

Such a solution would also have the virtue of allowing the use of USE
dependencies.  So, you would only install the .la files from a
particular library if another package actually needed them.  Packages
could also have USE defaults as seems logical to their maintainers and
distro policy.

Where this would get complex is if we want more than all-or-nothing
resolution.  The simplest USE approach would be to have it toggle all
the .la files in the package.  However, if you have 5 files that are
essential, and 5 that are likely nothing but trouble it will be harder
to manage that while still allowing full control.  I guess careful use
of local flags might work, in combination with some sane policy.  I'm
not sure if this is a use case that is even worth worrying about...

Rich

Re: [gentoo-dev] .la files and their future on Gentoo

[David Leverton]

On 3 October 2010 14:20, Richard Freeman <rich0@gentoo.org> wrote:
> Such a solution would also have the virtue of allowing the use of USE
> dependencies.  So, you would only install the .la files from a
> particular library if another package actually needed them.  Packages
> could also have USE defaults as seems logical to their maintainers and
> distro policy.

That's a good point - I did suggest not putting it in USE to avoid
cluttering things up for the sake of a use case that most people won't
need, but being able to do USE deps would be nice.  Maybe a
USE_EXPAND_HIDDEN variable could be a compromise, but that itself
could be confusing when a package wants to enable a flag that doesn't
appear to exist.  It probably depends on how often such a dep would
actually be needed - I suspect not very often.

> Where this would get complex is if we want more than all-or-nothing
> resolution.  The simplest USE approach would be to have it toggle all
> the .la files in the package.  However, if you have 5 files that are
> essential, and 5 that are likely nothing but trouble it will be harder
> to manage that while still allowing full control.  I guess careful use
> of local flags might work, in combination with some sane policy.  I'm
> not sure if this is a use case that is even worth worrying about...

I think that's unlikely to be a problem, but yes, local flags or the
like could be used if it ever does come up.

Re: [gentoo-dev] .la files and their future on Gentoo

[Luca Barbato]

On 10/03/2010 01:53 PM, David Leverton wrote:
> While I do agree that the underlying problem we're trying to solve is
> worth solving, I do have a couple of small concerns about how it's
> being done.  The first is that it seems people are judging whether a
> particular .la file is "needed" by checking whether anything currently
> in the tree needs it, but this doesn't take into account anything that
> /isn't/ in the tree yet.

I think the simpler solution is that if it needs .la, before reaching 
the tree it has to be fixed...

lu

-- 

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero

Re: [gentoo-dev] .la files and their future on Gentoo

[David Leverton]

On 3 October 2010 15:29, Luca Barbato <lu_zero@gentoo.org> wrote:
> I think the simpler solution is that if it needs .la, before reaching the
> tree it has to be fixed...

What I'm not keen about that is that using the .la files isn't really
"broken" - if libfoo uses libtool, and some other software uses
libfoo's .la files in a way that works with the upstream version of
libfoo, then it ought to work with Gentoo's libfoo too.  (This gets
into arguments about what sorts of changes are appropriate for a
distribution to make, versus being left to upstream.)

Also, not every piece of software that people might want to use is
going to go into the main tree - people can use Gentoo to develop
their own software (and might have their own ideas (or their
company/project's ideas) about what parts of libtool it's appropriate
to rely on), use packages from overlays, compile other people's
software outside the package management system, run precompiled
binaries, etc.  Again, from here I'm sure you can have a big
discussion about whether libraries in the tree exist only to support
applications in the tree, or whether they're "products" (for want of a
better word) in their own right.

Again, maybe not earth-shatteringly important issues, but I do think
these should at least be considered when deciding the policy.

[gentoo-dev] Re: .la files and their future on Gentoo

[Duncan]

David Leverton posted on Sun, 03 Oct 2010 16:39:39 +0100 as excerpted:

> Also, not every piece of software that people might want to use is going
> to go into the main tree - people can use Gentoo to develop their own
> software (and might have their own ideas (or their company/project's
> ideas) about what parts of libtool it's appropriate to rely on), use
> packages from overlays, compile other people's software outside the
> package management system, run precompiled binaries, etc.  Again, from
> here I'm sure you can have a big discussion about whether libraries in
> the tree exist only to support applications in the tree, or whether
> they're "products" (for want of a better word) in their own right.

The problem is that "in-tree" is a reasonably bounded set of builds, while 
"out-of-tree" is unlimited.  Practically speaking, I simply don't see how 
Gentoo can be concerned with "out-of-tree" in general, altho there's 
arguably a case that could be made for drawing the line /somewhat/ wider, 
say including official overlays as well, but even that very quickly 
becomes problematic as you're now expecting every dev with a candidate 
package to be familiar with every overlay it might affect.

No offense intended, and you do sort of make the point yourself with the 
"minor issue" thing, but arguably, this would be an /appropriate/ use of 
flameeyes' "people opposed are simply throwing up illegitimate blockages" 
complaint (where the binpkgs point wasn't, because that has long been a 
supported feature of Gentoo's primary PM and while breaking it may indeed 
be necessary, it's a legitimate point to raise).

OTOH, you do rightfully call it a minor point, perhaps one that shouldn't 
be a blocker, but one that should at least be raised.  Raising the point, 
minor and non-block tho it may be, in the discussion of record is a /good/ 
thing.  But I don't see how it's practical to do more than simply 
acknowledge it and say we can't let that block it (... except).

EXCEPT that the centralized controlling variable solution, via a removal 
method in EUTILS or the like, DOES make sense for any of a number of 
reasons, including that (a) centralizing the implementation is a good idea 
anyway, (b) once centralized, the implementation cost of a controlling 
variable is quite low, and (c), that makes it easy enough to control it 
either per-package or globally, using existing environment control 
solutions.

But beyond that, and for sub-package-level control, I simply don't see 
that it's practical.

But luckily, the above seems to fit your request as-is. =:^)  And as for 
sub-package-level, individual maintainers are still free to do what they 
believe is necessary with their packages, anyway.  (And for some packages 
and usages it /is/ arguably necessary.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: .la files and their future on Gentoo

[Richard Freeman]

On 10/03/2010 09:26 PM, Duncan wrote:
> The problem is that "in-tree" is a reasonably bounded set of builds, while 
> "out-of-tree" is unlimited.  Practically speaking, I simply don't see how 
> Gentoo can be concerned with "out-of-tree" in general.

If any other distro had that attitude Gentoo (and other source-based
distros) would be the only ones that provided packages for GCC, since no
other distro requires a functioning toolchain to install packages.

Libraries don't exist just to run packaged programs - they're also
needed to build new programs.  So, this is a use case that needs to be
considered.  Probably one of the reasons that Gentoo is popular among
developers is that it provides a very complete toolchain and libraries/etc.

That said, supporting this use case should not interfere with more
mainstream use of the distro.  I like the USE flag proposal because it
lets us have our cake and eat it too.  Those who don't need .la files
don't get them except where absolutely essential, and those who need and
are willing to live with tons of them can have it their way.

Gentoo is about choice...

Rich

[gentoo-dev] Re: Re: .la files and their future on Gentoo

[Diego Elio Pettenò]

[-- Attachment #1: Type: text/plain, Size: 1390 bytes --]

Il giorno lun, 04/10/2010 alle 11.19 -0400, Richard Freeman ha scritto:
> 
> That said, supporting this use case should not interfere with more
> mainstream use of the distro.  I like the USE flag proposal because it
> lets us have our cake and eat it too.  Those who don't need .la files
> don't get them except where absolutely essential, and those who need
> and
> are willing to live with tons of them can have it their way. 

USE flags add complexity, and in real use cases there are near to no
good reasons at all to keep .la files around.

I don't want to sound like a douchebag, but can you (or anyone else
supporting the USE flag notion) explain what .la files actually do?

What I'm quite sure of is that about half the people who express their
opinion regarding .la files have no idea what they are used for, they
expect them to be some kind of magic problem-solving fairy dust. They
are not.

They are a legacy of older operating system and static linking notions;
they are also not magical enough as they are only consumed back by
libtool. And not all the packages out there use libtool to link the
final application even if they were to use autotools.


-- 
Diego Elio Pettenò — “Flameeyes”
http://blog.flameeyes.eu/

If you found a .asc file in this mail and know not what it is,
it's a GnuPG digital signature: http://www.gnupg.org/


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: Re: .la files and their future on Gentoo

[Angelo Arrifano]

On 05-10-2010 03:55, Diego Elio Pettenò wrote:
> Il giorno lun, 04/10/2010 alle 11.19 -0400, Richard Freeman ha scritto:
>>
>> That said, supporting this use case should not interfere with more
>> mainstream use of the distro.  I like the USE flag proposal because it
>> lets us have our cake and eat it too.  Those who don't need .la files
>> don't get them except where absolutely essential, and those who need
>> and
>> are willing to live with tons of them can have it their way. 
> 
> USE flags add complexity, and in real use cases there are near to no
> good reasons at all to keep .la files around.

Like Richard said "Gentoo is about choice...

By removing .la files, you are taking away that choice from the user.
For you they might be useless, for some user (or entire software house)
it can be its holly grail for library versioning and linking. I don't
really feel like forcing users to change their build setups just because
we think they are useless, do you?
- It is decisions like this one that *might* give us bad reputation.

Should we also start removing package-config files just because there
are better ways to detect if a certain package is installed?
> 
> I don't want to sound like a douchebag, but can you (or anyone else
> supporting the USE flag notion) explain what .la files actually do?

You don't sound like a douchebag, just someone who wants to force stuff
into others. It happens all the time when we have strong feelings about
something or when we think we are totally correct. - But hey, guess
what? The world spins around sun after all.
> 
> What I'm quite sure of is that about half the people who express their
> opinion regarding .la files have no idea what they are used for, they
> expect them to be some kind of magic problem-solving fairy dust. They
> are not.

Careful.. There is people that might take this as an "attack"..
> 
> They are a legacy of older operating system and static linking notions;
> they are also not magical enough as they are only consumed back by
> libtool. And not all the packages out there use libtool to link the
> final application even if they were to use autotools.
> 
> 

[gentoo-dev] Re: Re: Re: .la files and their future on Gentoo

[Diego Elio Pettenò]

[-- Attachment #1: Type: text/plain, Size: 1827 bytes --]

Il giorno mar, 05/10/2010 alle 09.52 +0200, Angelo Arrifano ha scritto:
> 
> Like Richard said "Gentoo is about choice...
> 
> By removing .la files, you are taking away that choice from the user.
> For you they might be useless, for some user (or entire software
> house)
> it can be its holly grail for library versioning and linking. I don't
> really feel like forcing users to change their build setups just
> because
> we think they are useless, do you?
> - It is decisions like this one that *might* give us bad reputation.
> 
> Should we also start removing package-config files just because there
> are better ways to detect if a certain package is installed? 

Again, I ask you: how do libtool archive work? What is lost by removing
them? How can any software out there rely on them?

Can you provide any specific use case, or are you now arguing for
"choice for choice's sake"?

Should we remove /usr/bin/xml2-config? No. Why? Because there are
packages out there not using pkg-config to detect libxml2, upstream
libxml2 provides that explicitly and allows it to be used as such:

$(CC) $(CFLAGS) $(LDFLAGS) `xml2-config --cflags` foo.c -o foo
`xml2-config --libs`

Should we remove /usr/lib/libxml2.la? Yes. Why? Because upstream does
not explicitly provide it (it's a byproduct of libtool), and they don't
require/ask to rely on it (otherwise it wouldn't provide pkg-config
or .pc files).

Again, I'm not arguing over semantics or feelings here, I'm arguing with
facts; can you argue with facts or are you just going to quote Richard
again and propose "choice for choice's sake"?

-- 
Diego Elio Pettenò — “Flameeyes”
http://blog.flameeyes.eu/

If you found a .asc file in this mail and know not what it is,
it's a GnuPG digital signature: http://www.gnupg.org/


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: Re: Re: .la files and their future on Gentoo

[Angelo Arrifano]

On 05-10-2010 12:03, Diego Elio Pettenò wrote:
> Il giorno mar, 05/10/2010 alle 09.52 +0200, Angelo Arrifano ha scritto:
>>
>> Like Richard said "Gentoo is about choice...
>>
>> By removing .la files, you are taking away that choice from the user.
>> For you they might be useless, for some user (or entire software
>> house)
>> it can be its holly grail for library versioning and linking. I don't
>> really feel like forcing users to change their build setups just
>> because
>> we think they are useless, do you?
>> - It is decisions like this one that *might* give us bad reputation.
>>
>> Should we also start removing package-config files just because there
>> are better ways to detect if a certain package is installed? 
> 
> Again, I ask you: how do libtool archive work? What is lost by removing
> them? How can any software out there rely on them?

You can extract from a .la things like the library name, version and
linking information (lib dependencies and paths). The information is
there and nothing prevented anyone from using it.
> 
> Can you provide any specific use case, or are you now arguing for
> "choice for choice's sake"?

There are a lot of packages that need this information to correctly link
against libtool managed libraries, for example, there are packages that
linked against GL but didn't set -lGL -lGLU because it was relying on
libtool to get that information (guess from where?). Things get worse
when they also expect libtool to also provide libraries path. There are
even packages that expects libtool to provide linker flags for its
direct dependencies and flags for the dependencies of its dependencies.
For example:
foo links with GL (expects libtool to provide -lGL -lGLU)
foo also links with the backend of GL (expects libtool to provide -lX11
for example, which is a dependency of GL)

In a perfect world everyone would be using pkg-config or whatever, but
not. I happen to be bitching about this because I came across some of
these when cross-compiling.
> 
> Should we remove /usr/bin/xml2-config? No. Why? Because there are
> packages out there not using pkg-config to detect libxml2, upstream
> libxml2 provides that explicitly and allows it to be used as such:
> 
> $(CC) $(CFLAGS) $(LDFLAGS) `xml2-config --cflags` foo.c -o foo
> `xml2-config --libs`
> 
> Should we remove /usr/lib/libxml2.la? Yes. Why? Because upstream does
> not explicitly provide it (it's a byproduct of libtool), and they don't
> require/ask to rely on it (otherwise it wouldn't provide pkg-config
> or .pc files).
> 
> Again, I'm not arguing over semantics or feelings here, I'm arguing with
> facts; can you argue with facts or are you just going to quote Richard
> again and propose "choice for choice's sake"?
> 

Mind you that the community is wider than one can imagine. I happen to
work in the academia and I know a lot of nasty stuff people do to save
time (at least is what they think) for deadlines. As a user, I would
hate to have my research program/script broken just because some dev
decided to make the distribution I use his personal sandbox.

Besides, doesn't this kind of changes belong in upstream and then
eventually come to the distros? Why don't you make a patch and send
upstream if these libtool files are so useless?

[gentoo-dev] Re: Re: Re: Re: .la files and their future on Gentoo

[Diego Elio Pettenò]

[-- Attachment #1: Type: text/plain, Size: 2712 bytes --]

Il giorno mar, 05/10/2010 alle 13.04 +0200, Angelo Arrifano ha scritto:
> There are a lot of packages that need this information to correctly link
> against libtool managed libraries, for example, there are packages that
> linked against GL but didn't set -lGL -lGLU because it was relying on
> libtool to get that information (guess from where?).

Definitely not from /usr/lib/libGL.la given that libGL is part of mesa
and mesa did not use libtool for linking until very recently, so it's
either something relying on just the most recent versions of mesa, or
it's screwed. For your information, mesa has supported pkg-config for a
longer time than it used libtool to build.

Other interesting note: libGL on non-Xorg systems has no reason to use
libtool at all, even today.

Where does the linker find this information? For dynamic linking, from
the ELF files. The problem sticks for static linking, but I have my
sincere doubts that anyone in his sane mind is going to statically link
libGL for the simple reason that it can depend on the driver used (mesa,
nvidia, ATI, ...) and might even use dynamic linking against other
backends.

> Mind you that the community is wider than one can imagine. I happen to
> work in the academia and I know a lot of nasty stuff people do to save
> time (at least is what they think) for deadlines. As a user, I would
> hate to have my research program/script broken just because some dev
> decided to make the distribution I use his personal sandbox.

No, you'd just have to do things sanely. I sincerely don't see Gentoo
needing to not move forward (or add much more complexity in the already
complex mix) just because some student decided that it's cooler to hack
something up rather than learning how the thing is done to begin with.

We already don't support many other things that do break hacky scripts
that are written in academic (and not just) circles; does that mean we
have to revert those and pad around everything for our users, lest some
thing that never should have worked actually stop working?

> Besides, doesn't this kind of changes belong in upstream and then
> eventually come to the distros? Why don't you make a patch and send
> upstream if these libtool files are so useless?

I see you haven't read my post on the matter I linked at the root of the
thread. Please do so and don't ask me questions I answered already
there.

http://blog.flameeyes.eu/2010/10/04/libtool-archives-and-their-pointless-points

-- 
Diego Elio Pettenò — “Flameeyes”
http://blog.flameeyes.eu/

If you found a .asc file in this mail and know not what it is,
it's a GnuPG digital signature: http://www.gnupg.org/


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

[gentoo-dev] Re: Re: Re: Re: .la files and their future on Gentoo

[Diego Elio Pettenò]

[-- Attachment #1: Type: text/plain, Size: 656 bytes --]

Il giorno mar, 05/10/2010 alle 13.25 +0200, Diego Elio Pettenò ha
scritto:
> Definitely not from /usr/lib/libGL.la given that libGL is part of mesa
> and mesa did not use libtool for linking until very recently, 

Actually, scratch that, mesa IS NOT USING LIBTOOL AT ALL.

So you hit the jackpot: you brought up a libtool use case that... does
not use libtool at all! Congratulations!

Now, can you please let people express _informed_ opinions?

-- 
Diego Elio Pettenò — “Flameeyes”
http://blog.flameeyes.eu/

If you found a .asc file in this mail and know not what it is,
it's a GnuPG digital signature: http://www.gnupg.org/


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: Re: Re: Re: .la files and their future on Gentoo

[Angelo Arrifano]

On 05-10-2010 13:28, Diego Elio Pettenò wrote:
> Il giorno mar, 05/10/2010 alle 13.25 +0200, Diego Elio Pettenò ha
> scritto:
>> Definitely not from /usr/lib/libGL.la given that libGL is part of mesa
>> and mesa did not use libtool for linking until very recently, 
> 
> Actually, scratch that, mesa IS NOT USING LIBTOOL AT ALL.
> 
> So you hit the jackpot: you brought up a libtool use case that... does
> not use libtool at all! Congratulations!
> 
> Now, can you please let people express _informed_ opinions?
> 

I don't want to interrupt your celebration of winning a war or
something. Just want to say that mesa is not the only opengl
implementation. The examples I gave work with any other libtool managed
library.

Re: [gentoo-dev] Re: Re: Re: .la files and their future on Gentoo

[Samuli Suominen]

On 10/05/2010 02:04 PM, Angelo Arrifano wrote:
> You can extract from a .la things like the library name, version and
> linking information (lib dependencies and paths). The information is
> there and nothing prevented anyone from using it.
>>
>> Can you provide any specific use case, or are you now arguing for
>> "choice for choice's sake"?
> 
> There are a lot of packages that need this information to correctly link
> against libtool managed libraries, for example, there are packages that
> linked against GL but didn't set -lGL -lGLU because it was relying on
> libtool to get that information (guess from where?). Things get worse
> when they also expect libtool to also provide libraries path. There are
> even packages that expects libtool to provide linker flags for its
> direct dependencies and flags for the dependencies of its dependencies.
> For example:
> foo links with GL (expects libtool to provide -lGL -lGLU)
> foo also links with the backend of GL (expects libtool to provide -lX11
> for example, which is a dependency of GL)

Yeah, that's called overlinking[1]. There's no need to link to -lX11 if
really only -lGL is required. Exactly what we are trying to protect
users from.

Full stop.

[1] http://wiki.mandriva.com/en/Libtool_archives#shared_build

"Worse, default libtool causes overlinking when it uses *.la."

- Samuli

Re: [gentoo-dev] Re: Re: .la files and their future on Gentoo

[Luca Barbato]

On 10/5/10 9:52 AM, Angelo Arrifano wrote:

> By removing .la files, you are taking away that choice from the user.
> For you they might be useless, for some user (or entire software house)
> it can be its holly grail for library versioning and linking. I don't
> really feel like forcing users to change their build setups just because
> we think they are useless, do you?
> - It is decisions like this one that *might* give us bad reputation.

Bluntly put, you seem to not know how libtool exactly works and further 
down in the thread how linking exactly works. Please try to learn the 
fine Gentoo docs on the subject and feel free to ask more details on irc.

lu

Re: [gentoo-dev] Re: Re: .la files and their future on Gentoo

[Angelo Arrifano]

On 05-10-2010 13:49, Luca Barbato wrote:
> On 10/5/10 9:52 AM, Angelo Arrifano wrote:
> 
>> By removing .la files, you are taking away that choice from the user.
>> For you they might be useless, for some user (or entire software house)
>> it can be its holly grail for library versioning and linking. I don't
>> really feel like forcing users to change their build setups just because
>> we think they are useless, do you?
>> - It is decisions like this one that *might* give us bad reputation.
> 
> Bluntly put, you seem to not know how libtool exactly works and further
> down in the thread how linking exactly works. Please try to learn the
> fine Gentoo docs on the subject and feel free to ask more details on irc.
> 
> lu
> 
> 

I just talked with Samuli and Luca at IRC and indeed there were some
issues in my reasoning about libtool's behavior. Applications expecting
overlinking to link correctly would be broken anyway due to
-Wl,--as-needed .

Since all the issues I tried to point will not be verified anyway, I
don't see anymore why we can't proceed with the proposal. Moreover, due
to my past in fixing .la files to let programs cross-compile correctly I
actually welcome this change. So here it is my
+1

Re: [gentoo-dev] Re: Re: .la files and their future on Gentoo

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 636 bytes --]

On Tue, 05 Oct 2010 13:49:43 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:
> Bluntly put, you seem to not know how libtool exactly works and
> further down in the thread how linking exactly works. Please try to
> learn the fine Gentoo docs on the subject and feel free to ask more
> details on irc.

Ah, so you do know exactly how libtool works? Great! It should be easy
for you to fix it to only specify direct link dependencies then, thus
solving the underlying problem in one place rather than working around
it by fixing thousands of individual packages.

I look forward to testing your patch!

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: Re: .la files and their future on Gentoo

[Luca Barbato]

On 10/5/10 4:33 PM, Ciaran McCreesh wrote:
> On Tue, 05 Oct 2010 13:49:43 +0200
> Luca Barbato<lu_zero@gentoo.org>  wrote:
>> Bluntly put, you seem to not know how libtool exactly works and
>> further down in the thread how linking exactly works. Please try to
>> learn the fine Gentoo docs on the subject and feel free to ask more
>> details on irc.
>
> Ah, so you do know exactly how libtool works?

I had to face it in code to workaround some cases already, it hadn't 
been a nice experience.

> Great! It should be easy for you to fix it to only specify direct link
> dependencies then, thus solving the underlying problem in one place rather
> than working around it by fixing thousands of individual packages.

Sadly that would be already partially fixed by as-needed, the problem is 
that libtool mangles also library search paths when using .la files and 
that breaks in a number of situations we have in some sort of normal 
uses of Gentoo.

> I look forward to testing your patch!

The patch to avoid the issues by omitting the usage of .la in case 
--shared is provided is easy enough and solves quite well the problems 
mentioned.

lu

Re: [gentoo-dev] Re: Re: .la files and their future on Gentoo

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1044 bytes --]

On Tue, 05 Oct 2010 21:59:41 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:
> > Great! It should be easy for you to fix it to only specify direct
> > link dependencies then, thus solving the underlying problem in one
> > place rather than working around it by fixing thousands of
> > individual packages.
> 
> Sadly that would be already partially fixed by as-needed

as-needed fixes nothing. It works around some things, and introduces
some fairly icky problems as consequences. See the deleted comments on
Diego's blog posts for details.

> the problem is that libtool mangles also library search paths when
> using .la files and that breaks in a number of situations we have in
> some sort of normal uses of Gentoo.

Ah, so you'll be giving us a patch to test for that too, right? Fixing
the actual problem, rather than adding workarounds to a thousand or so
packages...

Good to see we're finally looking at addressing the root cause in one
place rather than trying to modify the entire tree.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: Re: .la files and their future on Gentoo

[Luca Barbato]

On 10/05/2010 10:20 PM, Ciaran McCreesh wrote:
> as-needed fixes nothing. It works around some things, and introduces
> some fairly icky problems as consequences. See the deleted comments on
> Diego's blog posts for details.

We discussed that to death, you are wrong abusing overlinking in your 
pet project and what you were asking for is exactly the as-needed behaviour.

>> the problem is that libtool mangles also library search paths when
>> using .la files and that breaks in a number of situations we have in
>> some sort of normal uses of Gentoo.

> Ah, so you'll be giving us a patch to test for that too, right? Fixing
> the actual problem, rather than adding workarounds to a thousand or so
> packages...

Apparently you do not know how libtool works or you are deliberately 
ignoring it... The patch is stupid (see below) but then you'd have to 
run libtoolize on every package you want to fix.

@@ -5936,7 +5936,7 @@
  	    searchdirs="$newlib_search_path $lib_search_path 
$sys_lib_search_path $shlib_search_path"
  	  fi
  	  for searchdir in $searchdirs; do
-	    for search_ext in .la $std_shrext .so .a; do
+	    for search_ext in $std_shrext .so .a .la; do
  	      # Search the libtool library
  	      lib="$searchdir/lib${name}${search_ext}"
  	      if test -f "$lib"; then



lu

-- 

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero

Re: [gentoo-dev] Re: Re: .la files and their future on Gentoo

[David Leverton]

On 6 October 2010 10:20, Luca Barbato <lu_zero@gentoo.org> wrote:
> We discussed that to death, you are wrong abusing overlinking in your pet
> project and what you were asking for is exactly the as-needed behaviour.

Clearly you have no clue what you're talking about here.

Re: [gentoo-dev] Re: Re: .la files and their future on Gentoo

[Jorge Manuel B. S. Vicetto]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06-10-2010 10:04, David Leverton wrote:
> On 6 October 2010 10:20, Luca Barbato <lu_zero@gentoo.org> wrote:
>> We discussed that to death, you are wrong abusing overlinking in your pet
>> project and what you were asking for is exactly the as-needed behaviour.
> 
> Clearly you have no clue what you're talking about here.

Please stop the discussion about --as-needed as that's not what's being
discussed here. We already had that discussion and made our decision
about that.

Let's also avoid the labelling of other people. The purpose here is to
have a technical discussion about la files, not calling names to anyone.

Before anyone asks, this mail isn't directed to David but to everyone
participating in this thread.

- -- 
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJMrFVDAAoJEC8ZTXQF1qEPdDkQAMmgY/W5HUhBWN2SdK6jyBSc
+XgAL1XfO4tc4o4ZbBznwfjeFC704mmOR2ZNYKagHGXdk+sNJ0sjMb5O2ov6PKkr
WYUIGBhhWriNZRtzmxHIvj97YHLASCYLdiaLr6tPVm+NEq+MApGYXiu8ElwgPZ9d
6RfxWs27ePiRKPun9xOHEnX4BL8w+IXrOmc0c+hncb9uontsprEcM2r25qpRHVmJ
vG+KCgafjESHiV/P++T7oiMNGaR0e8mEGzcVTrg0Ki+iPIcSIefx16QIFJl056m+
t6bQng/FG1LfLrXOvW7bjUkNdg3aMKZ/JluQqK3R+frOxOEFDmCt1lxqsrpAGHtA
wWQgupo36MBPGi+R9qv+/9WszFuT+r84sdM1BSDhU743oxIGDbrgoCKJuf+7MOkF
bOCEOwfwHd4LUXtSiZzTLlD5zeEwSKnxFJWOEWRXhGmICsPyZTkRhbKsLect04Ki
xUzt8Xfezvq80CVeI9J8g6TwciTgqhUIGP0e2xMUU05BCEoytV9E2c5PsHb66NAK
iaVVO9L5senC7KJYWDdsmdFBR/WNLcn45uMolxlJLhSol5shfkXXEjlGF91mxUa4
N9wzWI+QBYlxyQiZMr/aYGdyD34pJ13rGGfxkY3XAZlANKTwtSf1XrxI456Y35Jn
qa5P7us83qgl+HP0UvA5
=NE8V
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: Re: .la files and their future on Gentoo

[David Leverton]

On 5 October 2010 02:55, Diego Elio Pettenò <flameeyes@gmail.com> wrote:
> USE flags add complexity, and in real use cases there are near to no
> good reasons at all to keep .la files around.

That's why I initially suggested a variable rather than a USE flag, as
if it was implemented in a centralised function it wouldn't add
complexity to individual packages (no need to declare it in IUSE, for
example).  Although the USE flag approach has advantages too, as has
been mentioned.

> Also, I would like to ask again that if you're going to argue "you never
> know who might use them", you're going to have to actually understand
> _what_ the files are used for, _which_ software uses them, and come up
> with a use case for them, not a vague "oh there might be a project that
> use them".

The fact is that you /don't/ know what might use them.  Gentoo is a
general-purpose system, you can't predict what people will want to do
with it, including use software that relies on .la files from
libraries in the tree.  Obviously you can't support everything that
anyone might conceivably dream up, but keeping packages compatible
with their upstream state is a good place to start.

> Things like "taking in account what isn't in the tree" (without actually
> having a clue on what .la files are for)

So taking into account what isn't in the tree while knowing what .la
files are for is OK?

> looking for "alternative approaches" (to do what, exactly?)

Alternative approaches to fix the excessive dependency propagation
without breaking the semantics of libtool under static linking etc.

> Should we remove /usr/lib/libxml2.la? Yes. Why? Because upstream does
> not explicitly provide it (it's a byproduct of libtool)

What's the difference?

> and they don'trequire/ask to rely on it (otherwise it wouldn't
> provide pkg-config or .pc files).

pkg-config is useful because it's a standardised way to check for the
presence of other packages, including specific versions if necessary,
and to get the necessary include and library paths to use the library
- it's not the case that pkg-config is only supported for the sake of
avoiding libtool.  pkg-config /also/ overlaps with some functionality
of libtool, but that's not to say that no-one must ever use the
libtool functionality.

[gentoo-dev] Re: .la files and their future on Gentoo

[Duncan]

Richard Freeman posted on Mon, 04 Oct 2010 11:19:29 -0400 as excerpted:

> On 10/03/2010 09:26 PM, Duncan wrote:
>> The problem is that "in-tree" is a reasonably bounded set of builds,
>> while "out-of-tree" is unlimited.  Practically speaking, I simply don't
>> see how Gentoo can be concerned with "out-of-tree" in general.
> 
> If any other distro had that attitude Gentoo (and other source-based
> distros) would be the only ones that provided packages for GCC, since no
> other distro requires a functioning toolchain to install packages.

Interesting viewpoint.  But I disagree that it is so.  Rather, for binary 
distros, while gcc and the rest of the toolchain may not be /required/ for 
user-side maintenance of the distribution itself, they're certainly 
packages that provide a specific set of functionality.  As such, they're 
included in general distributions where such functionality may be desired, 
for much the same reason KDE or LAMP are included -- they are useful 
enough for a wide enough segment of the userbase to justify inclusion.  
OTOH, more specialized distributions may not include them, because they're 
simply not needed for the designated target usage.

In gentoo-speak, binary distributions include toolchain packages not as 
part of @system, but for those who wish to use them in their @world.

If Gentoo were therefore to take a binary distro approach, we'd do split-
packages.  Much as the binary distros have package-x and package-x-dev 
(which I'd guess include the *.la files, BTW), we'd have package-x and 
package-x-la, or some such.

Of course, the gentoo version of that is USE flags, FEATURES, etc.  Which 
means we're "in violent agreement!" =:^) and brings us back to...

> I like the USE flag proposal because it lets us have our cake and eat it
> too.  Those who don't need .la files don't get them except where
> absolutely essential, and those who need and are willing to live with
> tons of them can have it their way.
> 
> Gentoo is about choice...

The key-variable (whether USE flag, FEATURE, or a bit more hidden) based 
trigger does seem the pragmatic solution here.

Flameeyes, yes, I understand your objection to it on technical grounds as 
unnecessary complexity.  And I freely admit I'm not technically astute 
enough (in reality, probably few Gentoo devs are, with certain noted 
exceptions, of course) to debate you on the merits, there.  On the 
technical side, AFAIAC [1] you win by stipulation.

But there's more to life than being technically correct.  A centralized
la-file-stripper implementation seems to make sense in any case, and once 
it's centralized, exposing a control variable for it is little additional 
trouble.  Given the choice between allowing for the control variable in 
ordered to establish the necessary consensus and getting it deployed in 
months, vs either continuing to debate it for years or simply steamrolling 
it thru without that option, whatever the technical merits, I agree with 
rich0, the control variable seems the /clear/ winner, here.

Assuming that's the way it ultimately goes, what remains is to settle on 
the nature of the control variable.  There are merits in something 
slightly hidden, but OTOH, the USE flag idea has merits of its own.  It 
seems to me that the usual solution in similar cases is a USE flag, but 
masked.  So count this as a vote for a masked USE flag. =:^)

---
[1] AFAIAC: As Far as I am concerned:
http://www.onelook.com/cgi-bin/cgiwrap/bware/dofind.cgi?word=AFAIAC

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] .la files and their future on Gentoo

[Angelo Arrifano]

On 03-10-2010 15:29, Luca Barbato wrote:
> On 10/03/2010 01:53 PM, David Leverton wrote:
>> While I do agree that the underlying problem we're trying to solve is
>> worth solving, I do have a couple of small concerns about how it's
>> being done.  The first is that it seems people are judging whether a
>> particular .la file is "needed" by checking whether anything currently
>> in the tree needs it, but this doesn't take into account anything that
>> /isn't/ in the tree yet.
> 
> I think the simpler solution is that if it needs .la, before reaching
> the tree it has to be fixed...

<joke>
Was libtool deprecated or something? Judging by your reply, it really
made me think so.
</joke>

The farther we walk from upstream, the greater is the quantity of work
we have to do to maintain their packages.

> 
> lu
> 

Re: [gentoo-dev] .la files and their future on Gentoo

[Luca Barbato]

On 10/03/2010 06:57 PM, Angelo Arrifano wrote:
> <joke>
> Was libtool deprecated or something? Judging by your reply, it really
> made me think so.
> </joke>

<joke>
once everybody moves to scons/ffconf/whatever sure
</joke>

> The farther we walk from upstream, the greater is the quantity of work
> we have to do to maintain their packages.

Well I consider the .la sort of legacy byproduct of libtool and not 
something useful, probably in the future I'll send a patch to have the 
.la put as last item in search order for both libtool and libltdl to 
make it a non issue for everybody =P

lu

-- 

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero

Re: [gentoo-dev] .la files and their future on Gentoo

[Rémi Cardona]

Le 03/10/2010 16:29, Luca Barbato a écrit :
> I think the simpler solution is that if it needs .la, before reaching
> the tree it has to be fixed...

Using libltdl (libtool's dlopen wrapper) is a *legitimate* use of .la
files. Those programs do not need to be fixed as they are not broken.

The discussion here is about random apps and libs, that install .la
files for no other reason that they were *built* using libtool.

Such programs will work just fine without .la files. The only risk is
breaking :

 1) building other packages (see the dbus bug)
 2) building *static* programs/libs

#1 can be "fixed" using lafilefixer which sanitizes .la files so that
they stop referencing other .la files.

#2 is harder :

#2a) pkg-config is one solution (what upstream Xorg says: "if you want a
static libX11, use pkg-config --static"), other teams/herds could fix
their packages' .pc files to correctly list all required packages for
proper static linking. It's not rocket science.

#2b) drop support for static linking altogether. It can make sense for
some packages, but definitely isn't suitable for the entire portage tree.

So again, these are the only 2 issues we should be addressing.

Cheers,

Rémi

Re: [gentoo-dev] .la files and their future on Gentoo

[Luca Barbato]

On 10/04/2010 12:00 AM, Rémi Cardona wrote:
> Using libltdl (libtool's dlopen wrapper) is a*legitimate*  use of .la
> files. Those programs do not need to be fixed as they are not broken.

To my knowledge ltdl would load just fine the .so if the .la isn't found.

lu

-- 

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero

Re: [gentoo-dev] .la files and their future on Gentoo

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 558 bytes --]

On Mon, 04 Oct 2010 00:00:22 +0200
Rémi Cardona <remi@gentoo.org> wrote:

> #2a) pkg-config is one solution (what upstream Xorg says: "if you
> want a static libX11, use pkg-config --static"), other teams/herds
> could fix their packages' .pc files to correctly list all required
> packages for proper static linking. It's not rocket science.

AFAIK more .pc files rather need fixing to list only direct
dependencies when '--static' is not used. pkg-config itself takes care
of the dependencies pretty well.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] .la files and their future on Gentoo

[Rémi Cardona]

Le 04/10/2010 08:35, Michał Górny a écrit :
> On Mon, 04 Oct 2010 00:00:22 +0200
> Rémi Cardona <remi@gentoo.org> wrote:
> 
>> #2a) pkg-config is one solution (what upstream Xorg says: "if you
>> want a static libX11, use pkg-config --static"), other teams/herds
>> could fix their packages' .pc files to correctly list all required
>> packages for proper static linking. It's not rocket science.
> 
> AFAIK more .pc files rather need fixing to list only direct
> dependencies when '--static' is not used. pkg-config itself takes care
> of the dependencies pretty well.

Right, either way, .pc files usually need a little tweaking as devs
rarely touch them unless something is really broken. Patching (in
accordance with upstream of course) may be required.

But it's definitely my preferred solution (and a cross-platform one at
that!)

Cheers,

Rémi

Re: [gentoo-dev] .la files and their future on Gentoo

[Angelo Arrifano]

On 03-10-2010 12:53, David Leverton wrote:
> On 2 October 2010 20:54, Jorge Manuel B. S. Vicetto
> <jmbsvicetto@gentoo.org> wrote:
>> Given the recent activity around .la files and conflict about how to
>> deal with them, I propose we discuss this issue in this mailing list,
>> and take this issue to the council.
>> That way, we can make a global decision, taking into account all the
>> arguments for and against, find a balance, opt for a policy, inform
>> users and developers about it and move on.
> 
> While I do agree that the underlying problem we're trying to solve is
> worth solving, I do have a couple of small concerns about how it's
> being done.  The first is that it seems people are judging whether a
> particular .la file is "needed" by checking whether anything currently
> in the tree needs it, but this doesn't take into account anything that
> /isn't/ in the tree yet.

This is a very good point. However, in the case of out-of-tree packages,
I think most "regular" users just use ebuilds from bugzilla (and third
party places like forums etc). Users that contribute their cooked
ebuilds should know more or less what are doing, so I guess they will
have the corresponding packages patched in one way or another, if they
require a certain .la file.

>  The second is that removing .la files
> everywhere makes it hard for people to experiment with alternative
> solutions, as testing an alternative would require modifying all the
> affected ebuilds to stop removing them.  (And yes, I am interested in
> doing so myself, although time constraints mean it might not
> happening.)
> 
> Would it be too much trouble to have a standardised variable that
> means .la files should be kept?  It maybe /shouldn't/ be exposed as a
> USE flag because very few people will need it, but if it's easy to
> implement (maybe by having an eutils function to do the removal,
> checking the variable first) it would remove any objections I could
> imagine.

This seems like a very good solution. For example - usually, people
building packages manually just want the build process to work. They
don't want to spend time making an ebuild or digging around. One being
able to simply
USE="libtool" emerge foo
to restore the foo's .la files would be great.

A gentoo page properly indexed in Google and explaining what to do when
a libtool library is not found, should take care of most.

Another positive point about an .la USE flag is that users are already
used to put their USE flags on bugzilla, which should help package
maintainers to acknowledge .la related problems.
> 
> As I said, these are minor points, and I wouldn't expect people to go
> to great effort to satisfy them.  Just something to consider.
> 

Me being one of the persons that initially contributed code to allow
portage to fix .la files, I'm indeed happy to see the direction Gentoo
is heading. Libtool archives were (and still are for those not using
portage) a pain in the ass for cross-compilation.

Regards,
- Angelo

[gentoo-dev] Re: .la files and their future on Gentoo

[Diego Elio Pettenò]

[-- Attachment #1: Type: text/plain, Size: 3791 bytes --]

Il giorno sab, 02/10/2010 alle 19.54 +0000, Jorge Manuel B. S. Vicetto
ha scritto:
> 
> With that goal in mind, I'd like to ask anyone with arguments about
> this
> issue to present them as a reply to this thread. 

I'm going instead to link my latest blog post on the matter where I
summarised most of the points. Why a blog post? Because so I have it
available as reference for the future together with all the others.
Don't like that? Sorry, I don't care; I'm presenting information, if you
choose to not even look at it because I serve it via HTTP rather than a
mailing list, do state so; I'll make sure to ignore any of your opinions
in the future.

Now, stop with the less-than-friendly remarks, the content is at

http://blog.flameeyes.eu/2010/10/04/libtool-archives-and-their-pointless-points

Also, I would like to ask again that if you're going to argue "you never
know who might use them", you're going to have to actually understand
_what_ the files are used for, _which_ software uses them, and come up
with a use case for them, not a vague "oh there might be a project that
use them".

I might disagree with Nirbheek's assessment with the severity of the hit
on users (or rather, on the relative severity of it compared with the
alternative), but his reasoning is at least sound and based on real
concerns. Things like "taking in account what isn't in the
tree" (without actually having a clue on what .la files are for),
looking for "alternative approaches" (to do what, exactly?), or "fixing
what needs .la files" (why? if the package needs its own .la files to be
around and nothing else, just leave it be!) are not concerns that I care
about because they are not based on actual usefulness of .la files but
on vague ideas of either fending off the finding of a solution (I don't
want to know why, sincerely) or the idea that .la files are a binary
situation where you shouldn't have any at all.

From my point of view, the only points worth to be raised are Nirbheek's
(even though I disagree, as I said), Rémi's (which I don't think he
either considers showstoppers at this point) and those not-yet-spoken
off by Prefix (they might support architectures where .la files are
worth something).

Other than that, do we really have a problem here? Nirbheek's point
about stable will become moot next month; since we shouldn't revert the
changes that did go to stable, we're left with two main issues here:

 - is it okay to drop them from stable? my personal opinion here is to
side with Samuli and say "yes"; on the other hand, since by the looks of
it, and the status report Zac gave us, we're going to need just one
extra month before just telling users "install lafilefixer and update to
stable portage 2.1.9.13", I think we can avoid doing any more of those
changes till then — in stable that is; this includes both non-revbumps
and stable requests of packages dropping them;
 - what about Rémi's 2b concern? Sincerely I have worked for a long time
with static linking on my job and I don't see libtool files being so
excessively necessary; the only problem comes with transitive
dependencies, but most packages already take care of that; even if you
do not use pkg-config, you have other means to recover it.

On the other hand, I propose that if somebody have time on their hands
(I sincerely don't, unless somebody's going to hire me to, and I'm dead
serious), lafilefixer could be improved, and quick-stabled together with
the new portage in case, so that it saves the modified metadata in the
VDB.

-- 
Diego Elio Pettenò — “Flameeyes”
http://blog.flameeyes.eu/

If you found a .asc file in this mail and know not what it is,
it's a GnuPG digital signature: http://www.gnupg.org/


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: .la files and their future on Gentoo

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 870 bytes --]

On Tue, 05 Oct 2010 04:13:04 +0200
Diego Elio Pettenò <flameeyes@gmail.com> wrote:
> I'm going instead to link my latest blog post on the matter where I
> summarised most of the points. Why a blog post? Because so I have it
> available as reference for the future together with all the others.
> Don't like that? Sorry, I don't care; I'm presenting information, if
> you choose to not even look at it because I serve it via HTTP rather
> than a mailing list, do state so

I believe one of the larger objections to you providing information via
blog posts is that comments with constructive criticism or tricky
questions have a mysterious habit of not showing up there.

> I'll make sure to ignore any of your opinions in the future.

Unfortunately for Gentoo, many of the opinions you routinely ignore
happen to be useful ones.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: .la files and their future on Gentoo

[Enrico Weigelt]

* Diego Elio Pettenò <flameeyes@gmail.com> schrieb:

> http://blog.flameeyes.eu/2010/10/04/libtool-archives-and-their-pointless-points

ACK.

IMHO, removing the .la files should be under invididual ebuild
(or eclass) control, and we also should try to get it fixed 
at the source (if possible).

> Also, I would like to ask again that if you're going to argue "you never
> know who might use them", you're going to have to actually understand
> _what_ the files are used for, _which_ software uses them, and come up
> with a use case for them, not a vague "oh there might be a project that
> use them".

That whole "you'll never know who might use them"-idea is a bad idea,
IMHO. By that doctrine you can never get rid of old crap. Sometimes
an cut has to be made.

And for Distros, it doesnt make sense to try to support anything imaginable.
Instead there's limited (yet large) set of packages that are supported.
We can track the dependencies and so know who's using some particular
package (inside the distro). So we can actually test if removing la-files
from one invidual package will break anything. Maybe it's even worth
to make an automatic testsuite.

> From my point of view, the only points worth to be raised are Nirbheek's
> (even though I disagree, as I said), Rémi's (which I don't think he
> either considers showstoppers at this point) and those not-yet-spoken
> off by Prefix (they might support architectures where .la files are
> worth something).

Are there any platforms where .la files are really worth anything ?
(in Gentoo's scope) ? And *if* there're some - could there be better
solutions ?

BTW: In general, the idea of having a metadata file per library is
quite nice. (if done well, even better than the pkg-config approach).
But libtool implements this particular bad - it doesnt have a proper
abstraction (actually, libtool is not an abstraction at all, as eg.
unitool does, but just an command line filter doing mysterious things).

*If* someone here really likes the per-library-metadata idea, then
let's start an own project for that (knowing that'll be just reasearch
and not production-grade for quite some time). But that yet goes far
off-scope of distros (until a reasonable amount of packages adopted it).

>  - is it okay to drop them from stable? my personal opinion here is to
> side with Samuli and say "yes"; on the other hand, since by the looks of
> it, and the status report Zac gave us, we're going to need just one
> extra month before just telling users "install lafilefixer and update to
> stable portage 2.1.9.13", I think we can avoid doing any more of those
> changes till then ??? in stable that is; this includes both non-revbumps
> and stable requests of packages dropping them;

Admitting I've not fully followed this thread, but IMHO portage changes
aren't needed here - just put the la-skipping/-removal into individual
ebuilds. Portage can provide generic functions for that later, which
then can be used by newer ebuilds, but doesnt need to.

>  - what about Rémi's 2b concern? Sincerely I have worked for a long time
> with static linking on my job and I don't see libtool files being so
> excessively necessary; the only problem comes with transitive
> dependencies, but most packages already take care of that; even if you
> do not use pkg-config, you have other means to recover it.

I'm now working in embedded area (where static linking is quite common)
for about 10yrs, and pkg-config has proven quite well here. (packages
that dont provide .pc-descriptor yet, simply have to be fixed to do
so ;-p). Libtool, on the other hand, always had been a nightmare.


cu
-- 
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weigelt@metux.de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

Re: [gentoo-dev] Re: .la files and their future on Gentoo

[David Leverton]

On 5 October 2010 23:38, Enrico Weigelt <weigelt@metux.de> wrote:
> And for Distros, it doesnt make sense to try to support anything imaginable.

Not breaking things that already work would be a decent compromise.

> I'm now working in embedded area (where static linking is quite common)
> for about 10yrs, and pkg-config has proven quite well here. (packages
> that dont provide .pc-descriptor yet, simply have to be fixed to do
> so ;-p). Libtool, on the other hand, always had been a nightmare.

What about things that don't use pkg-config?  If you say "we don't
support that, modify it to use pkg-config", does that mean you're
willing to make Gentoo incompatible with Linux in general?  (That
question isn't just about .la files, it applies to any change versus
upstream that affects interfaces between components.)

Just to reiterate, I'm not trying to block anything here.  I'm just
asking for a small override so people with use-cases you (in general,
not a specific person) haven't thought of can be happy.  It doesn't
have to be officially supported or anything.  Is that really so
unreasonable?

Re: [gentoo-dev] Re: .la files and their future on Gentoo

[Enrico Weigelt]

* David Leverton <levertond@googlemail.com> schrieb:

> > And for Distros, it doesnt make sense to try to support anything imaginable.
> 
> Not breaking things that already work would be a decent compromise.

Any concerete example on what would break if .la files aren't 
installed anymore ?

> > I'm now working in embedded area (where static linking is quite common)
> > for about 10yrs, and pkg-config has proven quite well here. (packages
> > that dont provide .pc-descriptor yet, simply have to be fixed to do
> > so ;-p). Libtool, on the other hand, always had been a nightmare.
> 
> What about things that don't use pkg-config? 

As said above: fix them.

> If you say "we don't support that, modify it to use pkg-config", 
> does that mean you're willing to make Gentoo incompatible with
> Linux in general? 

This doesn't have to do anything w/ Linux - it's an purely userland
(and build-time only) issue, applicable to dozens of platforms.

When it comes to Gentoo (and maybe other distros) we only have to 
fix a few packages which don't use or support pkg-config yet,
but do libtool-based imports. In recent years, those became quite rare.

> (That question isn't just about .la files, it applies to any change
> versus upstream that affects interfaces between components.)

Are you sure, these .la files are really part of the interface for
most packages, but not just an side effect of using libtool ?

> Just to reiterate, I'm not trying to block anything here.  I'm just
> asking for a small override so people with use-cases you (in general,
> not a specific person) haven't thought of can be happy. 

In this case you'd need some kind of switch. Okay, let's just
introduce some make.conf variable for that and tell everybody
that there's no support for it whatsoever.


cu
-- 
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weigelt@metux.de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

Re: [gentoo-dev] Re: .la files and their future on Gentoo

[Alec Warner]

The portion that is not clear to me is why there is so much animosity
against a var to enable .la files.

I find the folks commenting to be very technical.  I trust that
removing .la files is the right choice to make here.  What I don't
grok is when someone makes a statement like 'removing .la files will
not break anything' or 'I understand exactly what affects this change
will have on the entire tree and the affects are trivial.'  I don't
think any one person can make statements like that.  The distribution
is large, our userbase is large, and the risk is difficult to
quantify.

Because of the above, adding a toggle to roll back the change seems
like a reasonable request.  If the idea is to add a remove_la_files
type function to eutils then the toggle can be added in a centralized
place.  If this change goes horribly awry and breaks the distribution
(or some subset of users) everyone has an easy revert (set some envvar
and rebuild everything...)

What I do not want to see is editing thousands of ebuilds to
'rollback' the change.  Nor do I want to see some complex procedure
where we have to slip in a different implementation of remove_la_files
to inhibit their deletion.  The work to add a rollback trigger is all
of 5 lines of bash; so why would we avoid adding it?

-A

On Mon, Oct 4, 2010 at 7:13 PM, Diego Elio Pettenò <flameeyes@gmail.com> wrote:
> Il giorno sab, 02/10/2010 alle 19.54 +0000, Jorge Manuel B. S. Vicetto
> ha scritto:
>>
>> With that goal in mind, I'd like to ask anyone with arguments about
>> this
>> issue to present them as a reply to this thread.
>
> I'm going instead to link my latest blog post on the matter where I
> summarised most of the points. Why a blog post? Because so I have it
> available as reference for the future together with all the others.
> Don't like that? Sorry, I don't care; I'm presenting information, if you
> choose to not even look at it because I serve it via HTTP rather than a
> mailing list, do state so; I'll make sure to ignore any of your opinions
> in the future.
>
> Now, stop with the less-than-friendly remarks, the content is at
>
> http://blog.flameeyes.eu/2010/10/04/libtool-archives-and-their-pointless-points
>
> Also, I would like to ask again that if you're going to argue "you never
> know who might use them", you're going to have to actually understand
> _what_ the files are used for, _which_ software uses them, and come up
> with a use case for them, not a vague "oh there might be a project that
> use them".
>
> I might disagree with Nirbheek's assessment with the severity of the hit
> on users (or rather, on the relative severity of it compared with the
> alternative), but his reasoning is at least sound and based on real
> concerns. Things like "taking in account what isn't in the
> tree" (without actually having a clue on what .la files are for),
> looking for "alternative approaches" (to do what, exactly?), or "fixing
> what needs .la files" (why? if the package needs its own .la files to be
> around and nothing else, just leave it be!) are not concerns that I care
> about because they are not based on actual usefulness of .la files but
> on vague ideas of either fending off the finding of a solution (I don't
> want to know why, sincerely) or the idea that .la files are a binary
> situation where you shouldn't have any at all.
>
> From my point of view, the only points worth to be raised are Nirbheek's
> (even though I disagree, as I said), Rémi's (which I don't think he
> either considers showstoppers at this point) and those not-yet-spoken
> off by Prefix (they might support architectures where .la files are
> worth something).
>
> Other than that, do we really have a problem here? Nirbheek's point
> about stable will become moot next month; since we shouldn't revert the
> changes that did go to stable, we're left with two main issues here:
>
>  - is it okay to drop them from stable? my personal opinion here is to
> side with Samuli and say "yes"; on the other hand, since by the looks of
> it, and the status report Zac gave us, we're going to need just one
> extra month before just telling users "install lafilefixer and update to
> stable portage 2.1.9.13", I think we can avoid doing any more of those
> changes till then — in stable that is; this includes both non-revbumps
> and stable requests of packages dropping them;
>  - what about Rémi's 2b concern? Sincerely I have worked for a long time
> with static linking on my job and I don't see libtool files being so
> excessively necessary; the only problem comes with transitive
> dependencies, but most packages already take care of that; even if you
> do not use pkg-config, you have other means to recover it.
>
> On the other hand, I propose that if somebody have time on their hands
> (I sincerely don't, unless somebody's going to hire me to, and I'm dead
> serious), lafilefixer could be improved, and quick-stabled together with
> the new portage in case, so that it saves the modified metadata in the
> VDB.
>
> --
> Diego Elio Pettenò — “Flameeyes”
> http://blog.flameeyes.eu/
>
> If you found a .asc file in this mail and know not what it is,
> it's a GnuPG digital signature: http://www.gnupg.org/
>
>

[gentoo-dev] Re: .la files and their future on Gentoo

[Duncan]

Alec Warner posted on Wed, 06 Oct 2010 21:45:51 -0700 as excerpted:

> The portion that is not clear to me is why there is so much animosity
> against a var to enable .la files.
> 
> [I trust the technical decision, but] when someone makes a statement
> like 'removing .la files will not break anything' [I get nervous.] I
> don't think any one person can make statements like that.  [The] risk is
> [too] difficult to quantify [like that].
> 
> Because of the above, adding a toggle to roll back the change seems like
> a reasonable request.  If the idea is to add a remove_la_files type
> function to eutils then the toggle can be added in a centralized place.

> The work to add a rollback trigger is all of 5 lines of bash;
> so why would we avoid adding it?

++

This is what I've been saying.  Centralizing it is a good idea anyway,
and once that's done, a control var is trivial.  Even if those objecting 
to systemic removal don't know what they're talking about, instituting 
this one trivial control var pretty well eliminates the opposition, and 
because implementation of such a control var /is/ trivial, doing it simply 
to eliminate the politics would seem the sensible thing.  We've already 
spent more time arguing about it than it'd take to implement the control 
var, and potentially enough to have it well documented as well! =:^\

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] Re: Re: .la files and their future on Gentoo

[Diego Elio Pettenò]

[-- Attachment #1: Type: text/plain, Size: 1737 bytes --]

Il giorno mer, 06/10/2010 alle 21.45 -0700, Alec Warner ha scritto:
> 
> Because of the above, adding a toggle to roll back the change seems
> like a reasonable request.  If the idea is to add a remove_la_files
> type function to eutils then the toggle can be added in a centralized
> place.  If this change goes horribly awry and breaks the distribution
> (or some subset of users) everyone has an easy revert (set some envvar
> and rebuild everything...) 

Do note: I have nothing against using a single function to wrap around

find "${D}" -name '*.la' -delete

it works pretty nicely also to avoid removing them for the eventual
platforms needing them (that is, if Prefix is interested in keeping them
around for any platform at all).

What I am against is _exposing the functionality to users_ (i.e. an USE
flag), as that is just going to confuse them and give us more hadaches
than it's worth.

If I cannot vouch for the entirety of the software base out there, I'm
still pretty sure it's the right way to do it for one reason: I've spent
three years writing, talking, and trying the .la files removal. Plus the
time I spent trying to deal with them between Gentoo/FreeBSD and
xine-lib. And I compared notes with other distributions.

Okay so maybe I come out a bit too strong; on the other hand I do find
it tremendously off-putting that people who have a vague idea of how the
files are consumed get to tell me that they should be kept for the sake
of it (or all deleted for the sake of it as well).

-- 
Diego Elio Pettenò — “Flameeyes”
http://blog.flameeyes.eu/

If you found a .asc file in this mail and know not what it is,
it's a GnuPG digital signature: http://www.gnupg.org/


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: Re: .la files and their future on Gentoo

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 787 bytes --]

On Thu, 07 Oct 2010 08:21:19 +0200
Diego Elio Pettenò <flameeyes@gmail.com> wrote:
> Okay so maybe I come out a bit too strong; on the other hand I do find
> it tremendously off-putting that people who have a vague idea of how
> the files are consumed get to tell me that they should be kept for
> the sake of it (or all deleted for the sake of it as well).

Diego, perhaps you'd find the whole thing less off-putting if you
considered the possibility that some of the people commenting know *at
least* as much as you do about libtool, and if you took the opportunity
to learn from their comments rather than trying to dictate something
that you can only claim is a perfect approach on media where you
dictate which remarks do and don't get posted.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: Re: .la files and their future on Gentoo

[Fabian Groffen]

On 07-10-2010 08:21:19 +0200, Diego Elio Pettenò wrote:
> Do note: I have nothing against using a single function to wrap around
> 
> find "${D}" -name '*.la' -delete
> 
> it works pretty nicely also to avoid removing them for the eventual
> platforms needing them (that is, if Prefix is interested in keeping them
> around for any platform at all).

Maybe it is necessary for our static-libs only platform(s).
In any case, a switch that can e.g. also be controlled through a profile
sounds like a nice thing if you people are going to push this forward.


-- 
Fabian Groffen
Gentoo on a different level