On Saturday 15 March 2008, Enrico Weigelt wrote: > * Alan McKinnon <[EMAIL PROTECTED]> wrote: > > A long time ago I read a HUGE thread on b.g.o. about this, the > > eventual conclusion is that after installation of a lib, a user > > might well want to link those libs statically and if they are not > > there, portage will barf big time and has no way to recover or even > > know what went wrong. Then the poor user sits in mystery wondering > > which package to remerge to get the .a > > Well, if there was an optional useflag (ie. "staticlib") which is > turned on by default (or maybe "nostaticlib"), I don't see any > problem. Most people will leave them enabled, only who are sure > about this will disable them.
OK, I see your reasoning. It fits in the same general category where "USE=build" belongs - highly specialized. However, I can predict with confidence that your chances of getting this accepted into portage are zero, for the following excellent reasons: 1. regardless of how many warning and how many FAQs state to not do it, a sizeable portion of idiots out there are going to enable it anyway "just to see what happens". We usually call these people ricers, it's the same twits who set CFLAGS=-O9999 and expect devs to help them out of the hole they dig for themselves. Most devs will take one look at this and decide why should they have their inbox filled with support mails from twits who do YADT (yet another dumb thing) at no real benefit to the dev himself? Heck, I wouldn't. 2. It's likely to break an unknown number of things in the tree. There is no easy way to know which ebuilds require a .a to be present, short of actually building everything in that state and seeing what breaks. Most devs would compare this to #1 and point blank refuse to support it for the same reason 3. Considering the current state of portage, good luck on finding a dev willing to build such a low-level feature into it :-) Getting it into paludis would be much easier IMHO In summary, you have an excellent chance of breaking stuff that isn't broken for an arguably zero or near-zero benefit > BTW: this leads me to another issue, which goes aroud in my mind for > a longer time: packages should be split off into several "stripes" > in the binary output. Other packages then could depend on single > stripes at different levels. For example: if some package foo > requires libbar, it would only depend on the buildtime stripe(s) for > building (eg. so headers get pulled in), while at runtime it will > only depend on the runtime stripe(s) of "bar". There could also be > separate stripes for certain locales, docs, examples, etc. > > Such an approach could be really useful for binary-only targets > (which don't build themselves) and network installations (eg. > arch-dependent and -independent stripes could be installed > separately). Well, you do only need the headers to build, but the whole point of building the app is to run it, which requires the binaries anyway. Frankly, it's easier to just manually delete the headers when the build is done > > Ubuntu can get away with this, the user gets what the packager > > feels like giving them, our users have *much* more freedom. > > I don't have much experiences w/ Ubuntu, but AFAIK this is an binary- > distro. Those distros usually split the (binary) output into two > separate packages, eg. "libfoo" is only the binary library, while > "libfoo-devel" contains all the buildtime stuff (*.h, *.pc, ...). > While this approach is quite simple, it's not very flexible and > does't allow finer granulation (eg. separating locales, etc), but > requires great care for filing dependencies. Yes, Ubuntu is binary. The packagers operate under policies that say things like "You will always use dynamic linking", so they could delete all static libs from the shipped packages, as any such package that requires a .a is by definition broken. The foo and foo-devel split is mostly a historical thing, dating from way back in the days of Red Hat 5 or even earlier. Back then, most users were on dial up (and binaries were much smaller than today) so -devel packages were introduced mostly to conserve bandwidth and resulting disk space. It's very much a hack actually. You could successfully argue that this is no longer the case and we don't need -devel packages anymore as bandwidth and disk space are cheap. Add the fact that -devel packages cause lots of confusion to users with mysterious failures when they build something. > > What's your reasoning for wanting to do this? > > a) saving space / skipping unused stuff > b) preventing accidential static linking. > > While working on PHP and IMAP c-client, I discovered a broken > libc-client.so* installation (turned out that just a symlink was > missing). PHP always tried to build in the static library (since .so > wasnt found), which leads to missing deps (eg. crypt,pam), after I > removed the explicit deps within PHP. The whole issue began with PHP > breaking at this point after I rebuild evrything w/o pam. PHP > explicitly links in pam and crypt for IMAP c-client if it finds them. > Obviously an dirty hack around libc-client's extremly poor > engineering. Hmmm. There are many thousand ebuilds in the tree. Many more in 3rd party overlays. Your idea fixes 1 problem in 1 ebuild. My vote goes to the solution that tells the php packager to find a work around for the problem that they can check in their ebuild without disrupting the result of the ecosystem -- Alan McKinnon alan dot mckinnon at gmail dot com -- gentoo-user@lists.gentoo.org mailing list
