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/
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
10-03-2010, 11:53 AM
David Leverton
.la files and their future on Gentoo
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.
10-03-2010, 01:20 PM
Richard Freeman
.la files and their future on Gentoo
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
10-03-2010, 01:39 PM
David Leverton
.la files and their future on Gentoo
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.
10-03-2010, 02:29 PM
Luca Barbato
.la files and their future on Gentoo
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...
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.
10-03-2010, 04:50 PM
Angelo Arrifano
.la files and their future on Gentoo
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
10-03-2010, 04:57 PM
Angelo Arrifano
.la files and their future on Gentoo
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
>
10-03-2010, 10:00 PM
Rémi Cardona
.la files and their future on Gentoo
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.