[gentoo-dev] Gentoo's plan to remove .la files: wording about when and how to drop .la files

[gentoo-dev] Gentoo's plan to remove .la files: wording about when and how to drop .la files

[Jorge Manuel B. S. Vicetto]

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

Hi.

As outlined in the global email about this issue, this email is to start
a thread about the wording on when and how to drop .la files. Please
reply to this thread if you have any comments about this point.


2. Get a consensus about the wording of when it's appropriate and how
it's appropriate to remove the .la files

As agreed in the meeting, as a first draft, we have that "the motion is
to drop la files, when appropriate, through the use of a function in
eutils that will only be called if the static-libs use flag is not set
or unless the package relies on pkg-config".
In the meantime there were some concerns raised about some prefix arches
and therefore there's a suggestion we use a hidden variable (not to be
set by users) to control the removal of the files so that we can "mask"
running the function on any profile where we can't drop the .la files.


- -- 
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/

iQIcBAEBAgAGBQJMzPD1AAoJEC8ZTXQF1qEPPZIP/j1zlxRQtPzq/sh9JpzR2yDg
wZsJR9F6+JzszWwlH/GGkIvATVv0GlNE5weDqzkcwMVjQuXN+MV/DIZ0/Nk7Tz/D
bDUjIankpC/Ngq0Qt1WUJ5M3NmdFD0PV2L1SsdgnMuphFGSOf95oGBHEUZL5GHM8
U6vY8VtRB14MFqS94vwE2T4Txj45X1k3K2r/oRagW5KAa8AeYXFSTV2bcW4+0Fjq
A9lZ3sn1pIeCT0QMFraAuX952wMx4U/sA5L1eYf0b4LsHWr+1S4Krhx1v87iYQK+
AnR42RwQOw9uNTN1n+/ubMZ1bJQS4zQFloGyTtCDu1DDOy3pkomKIFr3YaATq4Dj
mpbYI/LG12S2yPx/gqts6ncMiEbHHsI6z4SnDLvSfy1To2RFdpHIjFDGPslWndu2
TtED8QukmzOUGjQl8poWiBhIvPnV2w2P9ZetktSgOiLsCmT9jzAgtodZW01LLaDl
6HJETOSfvgb9oEObJiPtSWBFnu6OmvgGg82sfRPrzUiGtWO1x81eoGvOtXQpO2Bv
odgFGvkPkgAI7DDms6Nr2aaylVKOp5waSGnl6dkvLuDhTCFwPIvHDliDO7yOtuNJ
B0pZSSkoZPJa2Ydc/HESyCoiZjFY3Y2pVtgx8MFtgXAk+c0Ip9fs4RWoGSVpucUp
P8zEfxXj+F6MidciUIig
=Cncg
-----END PGP SIGNATURE-----

[gentoo-dev] Re: Gentoo's plan to remove .la files: wording about when and how to drop .la files

[Diego Elio Pettenò]

Il giorno dom, 31/10/2010 alle 03.30 -0100, Jorge Manuel B. S. Vicetto
ha scritto:
> As agreed in the meeting, as a first draft, we have that "the motion
> is
> to drop la files, when appropriate, through the use of a function in
> eutils that will only be called if the static-libs use flag is not set
> or unless the package relies on pkg-config". 

Let's differentiate already:

For *plugin* .la files, they should removed if the software is not
relying on them to load its plugins, see [1]. This is the case for PAM,
Python, Ruby and I guess Perl, which commonly receive stupid .la files
in their paths. Repeat after me: they should just all be deleted _right
now_ since they are not going to be linked by anyone else and thus
Portage 2.1.9 is not making any difference.

For *libraries* .la files, they should removed if:

 - you are not building any static archive at all (and this should
happen almost every time the library provides a plugin interface as the
plugins wouldn't work with a statically-linked archive);
 - the official way to link to the library is pkg-config or some other
-config package;
 - the package started as, or is evolving into, a non-autotools-based
package (most of X11 falls into this line since they started with imake
and that one never produced .la files so nobody should be relying on
them);
 - the library depends on no other library at all (so there are no
dependencies to cater);
 - finally, if USE=static-libs is set

Do note that static-libs USE flag causing the removal is the _least_
common case, quite very likely, you're going to stop at the second line
in my list and then delete the files. It's similar to what I wrote on
[2], by the way.


[1]
http://blog.flameeyes.eu/2009/07/06/identifying-pointless-la-files-for-plugins
[2]
http://blog.flameeyes.eu/2009/09/28/removing-la-files-for-dum-w-uncertain-people
-- 
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/

Re: [gentoo-dev] Re: Gentoo's plan to remove .la files: wording about when and how to drop .la files

[Pacho Ramos]

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

El dom, 31-10-2010 a las 14:56 +0100, Diego Elio Pettenò escribió:
> Il giorno dom, 31/10/2010 alle 03.30 -0100, Jorge Manuel B. S. Vicetto
> ha scritto:
> > As agreed in the meeting, as a first draft, we have that "the motion
> > is
> > to drop la files, when appropriate, through the use of a function in
> > eutils that will only be called if the static-libs use flag is not set
> > or unless the package relies on pkg-config". 
> 
> Let's differentiate already:
> 
> For *plugin* .la files, they should removed if the software is not
> relying on them to load its plugins, see [1]. This is the case for PAM,
> Python, Ruby and I guess Perl, which commonly receive stupid .la files
> in their paths. Repeat after me: they should just all be deleted _right
> now_ since they are not going to be linked by anyone else and thus
> Portage 2.1.9 is not making any difference.
> 

In that case, I think the work on these cases should start as soon as
possible, but I think that getting bugs reported (probably from your
next tinderbox run if possible) would help. For example, I have just
seen in my system that packages like dev-python/pyorbit and
dev-libs/libgamin are installing these .la files that should not be
needed, but I am sure lots of other python packages are also
affected :-/.

But I would also like to know what would be the best way to drop them in
these cases:
- For python, looks like calling python_clean_installation_image from
python.eclass at src_install phase is the proper way.
- For pam, ruby or perl I have no idea :-(

Thanks

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

[gentoo-dev] Re: Re: Gentoo's plan to remove .la files: wording about when and how to drop .la files

[Diego Elio Pettenò]

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

Il giorno dom, 31/10/2010 alle 15.31 +0100, Pacho Ramos ha scritto:
> In that case, I think the work on these cases should start as soon as
> possible,

I have said that before.

> but I think that getting bugs reported (probably from your
> next tinderbox run if possible) would help.

Search for "pointless .la" and you'll find a bunch of reported bugs; I
stopped mostly because of GNOME-related packages (which where the main
cause of the bugs):

 - Tester refused fixing telepathy and the like altogether stating that
it's an upstream issue;
 - leio stated that he didn't care about removing those that are simply
pointless already because he wanted to do it in one big sweep, and the
bugs I would report would just linger there indefinitely.

>  For example, I have just
> seen in my system that packages like dev-python/pyorbit and
> dev-libs/libgamin are installing these .la files that should not be
> needed, but I am sure lots of other python packages are also
> affected :-/.

dev-libs/libbeagle (maintainer-needed)
sys-auth/fprintd (xmw)
dev-python/pygoocanvas (gnome/python)
x11-libs/xpyb (x11)
media-libs/hamlib (tomjbe)
net-libs/gtk-vnc (gnome)
dev-python/pyclutter-gtk (gnome)
dev-python/pyclutter (gnome)
media-libs/pdflib (maintainer-needed)
dev-libs/libnatspec (invalid metadata?)
dev-python/notify-python (dev-zero/python)
dev-python/telepathy-farsight (nirbheek/tester/voip)
sci-libs/geos (sci-geosciences/postgres)
sys-libs/libieee1284 (base-system)
app-i18n/libtomoe-gtk (cjk)
app-i18n/tomoe (cjk)
net-libs/farsight2 (voip)
x11-libs/vte (gnome)
dev-python/pyorbit (gnome)
gnome-extra/libgsf (gnome)
dev-python/pygtksourceview (gnome)
gnome-base/gnome-keyring (gnome)
dev-libs/libxslt (gnome)

And this is just a list I produced out of the current logs I have on the
tinderbox (64-bit version) for the paths of the plugins I _know_ are not
loaded through .la files… I think there are a few hundreds .la files in
packages maintained by gnome alone that are not being used at all and
could have been removed years ago (reducing the pressure of
revdep-rebuild on broken .la files).

> - For pam, ruby or perl I have no idea :-(

find $(get_pammoddir) -name '*.la' -delete
find /usr/$(get_libdir)/ruby -name '*.la' -delete

Nothing fancy, just delete them ;)

-- 
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: Gentoo's plan to remove .la files: wording about when and how to drop .la files

[Thomas Beierlein]

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

On Sun, 31 Oct 2010 15:52:51 +0100
Diego Elio Pettenò <flameeyes@gmail.com> wrote:

> >  For example, I have just
> > seen in my system that packages like dev-python/pyorbit and
> > dev-libs/libgamin are installing these .la files that should not be
> > needed, but I am sure lots of other python packages are also
> > affected :-/.
> 
snip..
> media-libs/hamlib (tomjbe)
snip..

Above package provides around 38 .la files. I am not quite sure yet
about hamlibtcl.la, libhamlib++.la, libhamlib.la and _Hamlib.la. Maybe
they can go -- will look into that in next days.

But the other ones are plugins (or backends in hamlib terms) which get
loaded via libltdl according to the radio tranceiver family in question.

See as an example the following strace for calling the simple frontend
(rigctl) for the Kenwood TS-570 tranceiver (Model 204).

strace -e open rigctl -m 204
open("/etc/ld.so.cache", O_RDONLY)      = 3
open("/usr/lib64/hamlib/libhamlib.so.2", O_RDONLY) = 3
open("/lib/libpthread.so.0", O_RDONLY)  = 3
open("/lib/libc.so.6", O_RDONLY)        = 3
open("/usr/lib/libltdl.so.7", O_RDONLY) = 3
open("/lib/libm.so.6", O_RDONLY)        = 3
open("/lib/libusb-0.1.so.4", O_RDONLY)  = 3
open("/lib/libdl.so.2", O_RDONLY)       = 3
open("/usr/lib64/hamlib/hamlib-kenwood.la", O_RDONLY) = 3
open("/usr/lib64/hamlib/hamlib-kenwood.so", O_RDONLY) = 3
open("/dev/ttyS0", O_RDWR|O_NOCTTY|O_NONBLOCK) = 3


If I read the discussion correctly we will still need to keep these .la
files around.

Regards,
	Thomas.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)

iEYEARECAAYFAkzNvuQACgkQQe4uqXYgU9XQOACfdh6Y0K4tEaNfxZWuLQ4IKY9z
COcAniZAbl1YcvRLrGQE6k2Jph2jNOkN
=u989
-----END PGP SIGNATURE-----

[gentoo-dev] Re: Re: Re: Gentoo's plan to remove .la files: wording about when and how to drop .la files

[Diego Elio Pettenò]

Il giorno dom, 31/10/2010 alle 20.09 +0100, Thomas Beierlein ha scritto:
> 
> If I read the discussion correctly we will still need to keep
> these .la
> files around.
> 
Most likely, yes… you can go a bit deeper about them (for instance
PulseAudio can load its plugins with libltdl even if the .la files are
not around, and the author _always_ recommended removing them), but
that's probably something we don't have to care about so much as it is.

For what concerns the list I provided, that's just the output of the
tinderbox in the case of hamlib, it was _Hamlib.la that triggered it, it
is installed in the Python tree and Python does not use .la files.

-- 
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/

Re: [gentoo-dev] Re: Re: Re: Gentoo's plan to remove .la files: wording about when and how to drop .la files

[Thomas Beierlein]

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

On Sun, 31 Oct 2010 20:15:17 +0100
Diego Elio Pettenò <flameeyes@gmail.com> wrote:

> Il giorno dom, 31/10/2010 alle 20.09 +0100, Thomas Beierlein ha
> scritto:
> > 
> > If I read the discussion correctly we will still need to keep
> > these .la
> > files around.
> > 
> Most likely, yes… you can go a bit deeper about them (for instance
> PulseAudio can load its plugins with libltdl even if the .la files are
> not around, and the author _always_ recommended removing them), but
> that's probably something we don't have to care about so much as it
> is.
> 
Anyway, I will look into it and try it out.

> For what concerns the list I provided, that's just the output of the
> tinderbox in the case of hamlib, it was _Hamlib.la that triggered it,
> it is installed in the Python tree and Python does not use .la files.
> 
Ok. Thnaks for the info. Another one will be libhamlib.la as it works
with pkg-config - so no need for it.

Regards,

	Thomas.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)

iEYEARECAAYFAkzN3JcACgkQQe4uqXYgU9WejwCdFbv1YtXLgunYF0FVXyZWJUmA
2igAn2XloPLjVitP0n0Sh3f9oDi3LOue
=asZZ
-----END PGP SIGNATURE-----