Re: [gentoo-dev] Re: .la files and their future on Gentoo
* David Leverton levert...@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: weig...@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
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ò flamee...@gmail.com wrote: Il giorno sab, 02/10/2010 alle 19.54 +, 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
Re: [gentoo-dev] Re: .la files and their future on Gentoo
On Tue, 05 Oct 2010 04:13:04 +0200 Diego Elio Pettenò flamee...@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 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: .la files and their future on Gentoo
* Diego Elio Pettenò flamee...@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: weig...@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
On 5 October 2010 23:38, Enrico Weigelt weig...@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
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: .la files and their future on Gentoo
Il giorno sab, 02/10/2010 alle 19.54 +, 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/ signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: .la files and their future on Gentoo
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
[gentoo-dev] Re: .la files and their future on Gentoo
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
