19:29 <@nirbheek> aidecoe, static libs should be disabled with --disable-static, .la files can be removed with a find command 19:29 <@nirbheek> find "${D}" -name '*.la' -exec rm -f '{}' + 19:29 <@nirbheek> This should do the trick (if you want to get rid of them all) 19:29 <@aidecoe> nirbheek: i'm using autotools-utils for handling static-libs 19:29 <@nirbheek> aidecoe, okay, cool, then you want to make that find conditional on use static-libs 19:29 <@Betelgeuse> nirbheek: why not use -delete from find itself? 19:29 <@Betelgeuse> nirbheek: Not BSD safe? 19:29 <@nirbheek> Betelgeuse, yeah, that's what I was informed about by ssuominen 19:30 <@aidecoe> oh, good to know. I'd use -delete, too 19:30 <@Betelgeuse> nirbheek: Any way finds like that should be abstracted to eclasses. 19:30 <@Betelgeuse> Or PM. 19:30 <@ABCD> -delete works on ~*-freebsd (prefix), but not ~*-fbsd (Gentoo/FreeBSD) 19:30 <@nirbheek> Betelgeuse, gnome2.eclass already does that in the overlay, that'll be moved to tree in the future 19:30 <@nirbheek> Betelgeuse, we use the variable GNOME2_LA_PUNT="yes" 19:31 <@nirbheek> http://dpaste.com/476339/ <-- at the end of src_install 19:31 <@ABCD> and for future reference (so people don't get confused), in EAPI 3+, `find "${D}" -name ....` and `find "${ED}" -name ...` are guaranteed to find exactly the same files (as no files exist in $D that are not in $ED) 19:32 <@Betelgeuse> If we are aiming to get rid of them by default let's make EAPI 5 remove them and then have a variable to keep them for special cases. 19:33 * nirbheek wonders why we haven't done this already
(In reply to comment #0) > 19:32 <@Betelgeuse> If we are aiming to get rid of them by default let's make > EAPI 5 remove them and then have a variable to keep them for special cases. > 19:33 * nirbheek wonders why we haven't done this already You probably want the variable to be a list of paths so that specific files can be whitelisted, for example, gnome-applets installs /usr/share/xmodmap/xmodmap.la but it's not really a libtool archive (bug #340725).
Finding out which la files are needed might be a bit tricky, i.e. there's no obvious reason for libltdl.la existence, but IIRC LTDL_INIT (previously AC_LIB_LTDL) checks for its presence. Though I've been on wide spread removal side for awhile.
The way autotools-utils.eclass works is just broken because it doesn't check if the package has valid pkg-config files that renders those .la files useless that otherwise would be useful. I'd prefer simple way, without trying to make too much assumptions, and simply delete all *.la files (maybe check existance of dependency_libs or something else that they are in fact libtool files and not some other files) if some variable is not set to keep them around
What is delaying this? Ciaran referred to some problems with "specification" in https://bugs.gentoo.org/show_bug.cgi?id=366071#c27 but I don't have any idea about what is really missing and how could I help to move this ahead :-/
We need a full description of exactly what the package mangler needs to do, along with a way of handling exceptions.
(In reply to comment #5) > We need a full description of exactly what the package mangler needs to do, > along with a way of handling exceptions. About exceptions handling, looks like most of us agree with simply set a variable to keep them in that cases. About how to remove them, per comment #3 looks like removing all of them by default would be better (and it doesn't seem too unsafe to me as, due eapi bump, people would need to check if anything breaks before bumping to new eapi and see all .la files removed). In gnome2.eclass we are using the following command to remove them: find "${D}" -name '*.la' -exec rm -f {} + That looks to work also for *bsd
And how does this fit in with the big complicated script that Portage is currently running?
(In reply to comment #7) > And how does this fit in with the big complicated script that Portage is > currently running? I don't know if it would still be needed once .la files are removed, the problem is that, as the tree would move slowly to the new eapi, during the time older EAPIs still installing .la files and new one coexist, that lafilefixing would still be required for packages still installing .la files (I think zmedico is in pms mail alias, surely he will know much more than me about this problem :))
The script touches la files only. That means if no package installs la files, the script has no longer any effect and is no longer needed. This bug is not directly related to portage's FEATURES="fixlafiles". As I understand it, Ciaran asked for an EAPI specification for what the script does and not for the removal of la files. First of all you can disable it in portage, so relying on it is wrong and bug 366071 should simply be fixed. Why has this script been added to portage? Users were facing repeated breakage because of the removal of la files. Installed la files were still referencing now gone la files and packages failed to build because of this. And this happend again and again, causing frustation for our users. Now you can argue that the procedure for removing la files should be fixed. IIRC some people tried that on the dev-ml, but it didn't work out. As a consequence this script was added to portage. After that, the la file removal related build failures disappeared.
The problem is that, since during a long time packages installing .la files and packages removing them (using new eapi) will coexist, that script will still be needed, no?
(In reply to comment #10) > The problem is that, since during a long time packages installing .la files and > packages removing them (using new eapi) will coexist, that script will still be > needed, no? Right. Without the script, every EAPI bump of a package that used to install la files will break all the reverse dependencies that install la files referencing the now removed la file (unless you use the proposed variable to keep the la file, of course).
Then, all supported package managers will need to implement a similar feature as will be impossible to migrate from a tree installing la files to a new one not installing them and using eapi5 :-/. And that script will need to be run for all ebuilds and eapis installing .la files
Which means the script's behaviour needs to be fully specified...
Maybe some portage team member could specify its behavior since I don't have much idea about it :-(
(In reply to comment #13) > Which means the script's behaviour needs to be fully specified... @Ciaran: Would you support adding this to all existing EAPIs?
No. It needs to be removed from Portage for older EAPIs and only done for new EAPIs. Retroactively changing things is only fine when doing so causes no breakage to older package mangler releases.
(In reply to comment #16) > No. It needs to be removed from Portage for older EAPIs and only done for new > EAPIs. Retroactively changing things is only fine when doing so causes no > breakage to older package mangler releases. This falls a bit into INSTALL_MASK territory (pkg manager features), although ebuilds can't rely on it... Either way; alternatively, push a shell implementation into an eclass that runs during preinst if the manager doesn't export a var indicating it can handle it itself. In the same vein, the eclass would need to signal the manager that it wants .la cleansing- properties or an env var comes to mind. Doing so wouldn't break backwards compatibility via the fallback implementation; from there just push it into EAPI5.
Why not just do the entire thing via an eclass?
(In reply to comment #18) > Why not just do the entire thing via an eclass? Requiring every tree that's out there to treat gentoo-x86 as a master isn't particularly grand; meaning it needs to fold into PMS sooner rather than later. If this behaviour is decided upon, having it cross eapi boundaries is just going to waste developer time. Eclass route gets things started allowing it to be deployed now, while managers deploy equivalent support. Down the line, can retroactively mangle the spec for it if needed if eapi0-4 aren't dead/phased out. Basically it's a pragmatic integration of the feature while minimizing the fallout, and avoiding making devs lives mildly pissy (or requiring crap like always inheriting gentoo-x86 or copy/pasting of that eclass into 101 repositories).
Why can't this be treated like a PM feature? Ebuilds relying on it need to be fixed and that's it.
That's a good start, but so long as Portage has it on by default, ebuilds aren't going to get fixed...
(In reply to comment #21) > That's a good start, but so long as Portage has it on by default, ebuilds > aren't going to get fixed... I know only about one single bug. This bug seems to be caused by a partial removal of la files and the remaining la files referencing one of the removed ones. That this bug is not fixed seems to be a lack of a proper solution than unwillingness to fix it. Providing an eclass function that can be called for those special packages seems reasonable to me.
(In reply to comment #21) > That's a good start, but so long as Portage has it on by default, ebuilds > aren't going to get fixed... Before that code was added to portage, I remember some other ebuilds (I think mozilla/xulrunner related) asked to run manually "lafilefixer --justfixit" to let them compile ok... and that solution looks worse to me than portage script :-/ How would we handle that cases of packages needing to run "lafilefixer" manually to clean .la files? Can that cases be solved in other way? (In that case, I don't understand why lafilefixer was even developed...)
Is this thing alive still? We've got a mostly-proper removal function now in eutils -- and I personally think it's too complex for including in PMS. That said, if we decide to have .la removal in PMS it'll most likely be a total, unconditional removal of them all. Which means that packages which don't have proper pkg-config files would either have to: a) introduce custom pkg-config files -- and this is mostly the wrong thing to do since those files will be Gentoo-specific. b) drop static-libs completely -- likely the simplest and best thing to do. c) conditionally disable removing .la files -- which will make the spec more complex but will work. The question is -- whether we really want this. To be honest, I doubt this is going to make things simpler for us. A bit better, faster -- maybe. But we'd have to make sure all the corner cases aren't broken by hand -- which prune_libtool_files attempts to solve automatically. On the other hand, there is a few developers who thoughtlessly put '--all' onto prune_libtool_files already and don't care about the results. That said, we may as well drop them all by default.
(In reply to Michał Górny from comment #24) No further reply since more that two years, therefore closing.
it is not safe to blindly delete all .la files. libltdl relies on them when loading plugins in order to figure out what files are needed. simple example: $ convert mog.gif mog.png <works> $ sudo mv /usr/lib64/ImageMagick-*/modules-*/coders/{gif,png}.la ~/ $ convert mog.gif mog.png convert: no decode delegate for this image format `GIF' @ error/constitute.c/ReadImage/501. convert: no images defined `mog.png' @ error/convert.c/ConvertImageCommand/3230. having the PM try and analyze/guess the intentions of the .la files seems overly dangerous to me.
