| |||||||||||||
|
| |||||||||||||
I'm a Gentoo HoldoutI'm a Gentoo HoldoutPosted Nov 20, 2003 6:18 UTC (Thu) by torsten (guest, #4137)Parent article: The Success of Gentoo I've had Gentoo recommended to me many a time, but I still haven't tried it. I worry about the Linux community reliance on "package maintainers" and script maintainers. By automating many of the things that are done manually by maintainers, we can reduce bugs, human error, and save thousands of hours of developer time. I am also unconvinced that the portage system solves the dependency problem, rather, it seems to band-aid it. *Shouldn't we embed dependency information, compile options, and the many other attributes specific to a program [and defined in a portage script] in the program's source code or binary? *Shouldn't these attributes be automatically generated by gcc or a script during programming-time? It seems to me most of the information in the portage system is manually maintained, and it could be automated. Am I missing something?
(Log in to post comments)
I'm a Gentoo Holdout Posted Nov 20, 2003 7:58 UTC (Thu) by nix (subscriber, #2304) [Link] Embedding of dependency information is already done for shared libraries, of course (DT_NEEDED). We could always add something for non-shared-libraries, but they'd be useless to the binary itself and we'd need a call of some kind (or an extension to libbfd) to get access to them. Both seem rather painful.Secondly, we'd need to store the dependency information elsewhere *anyway*, or how else does it get into the binary? Embedding of compilation options into binaries has been suggested, but nobody can think of very much use for it. Embedding compilation options into *source code* is something that many people have wished for (mostly to turn on or off erroneous warnings over short blocks of code); but nobody's done the work yet.
I'm a Gentoo Holdout Posted Nov 20, 2003 8:01 UTC (Thu) by Klavs (subscriber, #10563) [Link] >*Shouldn't we embed dependency information, compile options, and the many >other attributes specific to a program [and defined in a portage script] in >the program's source code or binary?Sure. If you think you are going to get everyone who develops software to do this right - then feel free :) Besides that part is pretty easy to do in the portage ebuild scripts. The harder part is those that do not follow the ./configure && make && make install way of doing things to the letter :) And even that is best done in portage ebuilds. And I say this, having written RPM .spec files for many years. >*Shouldn't these attributes be automatically generated by gcc or a script >during programming-time? Contribute your ideas (see the Gentoo GLEP proposal for bigger ideas) that's what it's all about. Just waiting out till someone else does it, might just mean it never gets done ;)
I'm a Gentoo Holdout Posted Nov 20, 2003 8:52 UTC (Thu) by omez (guest, #6904) [Link] Embeding the dependency information and whatnot in the original source doesn't obviate the need for someone to manually intervene at some point. You'll still have the same number of bugs, errors, and time spent combating them. An automated tool would involve all 4,700 projects (in just the Gentoo case) adopting a single package system. And just how are you going to convince every distro of every Unix and Unix-like system to follow suit? There are projects that don't even use autoconf, much less favor a particular packaging system. It couldn't compete with the distro-agnostic, write once, run anywhere approach of good, portable code.The ebuild maintainers are very responsive. Rather than consult the project's roadmap to determine when a fix can go out, they just do it. They put the "early and often" shine on the most glacial of development styles.
|
|
||||||||||||