Zac Medico wrote: [Wed Jun 07 2006, 01:30:38PM CDT] > Mike Frysinger wrote: > > this is a *huge* con ... developers are lazy, *i'm* lazy ... i > > certainly do not want to go through every single package i maintain > > and add 'debug-build' to IUSE or 'inherit some-new-eclass' > > Sometimes it takes a little extra work to do things right, but > hopefully it will pay off in the long run. A poor design decision > made now can haunt us for years to come.
A "little extra work"? I'm pretty sure that such an eclass would be required for better than half the tree (every package that contains some C or C++). If almost everybody has to add the same piece of boilerplate to their ebuilds, then perhaps a sane package manager should be able to figure out what to do without the boilerplate. That rationale seems especially true in this case, where nostrip and debugging flags will do no harm for packages that aren't C or C++. > > if the large majority of packages are going to be taking advantage of a > > feature, isnt the logical thing to opt everyone in rather than forcing the > > majority to opt themselves in ? > > It really depends on the pros/cons applying something on a *global* > scale, like you propose. A package manager (such as portage) will > never be able to make debug-build decisions that work well for *every* > ebuild. That's why it's better for ebuilds to make those decisions > themselves (with the help of eclasses). I would think that your argument would depend on the probability of a package being an exception to the general rule. How many packages actually fail to do what is expected when compiled with -g and nostrip (noting that those cases without binaries to strip don't count)? Unless that percentage is significant, then I would think that a simple solution that handles the common case is a very good thing. Wouldn't the "simple" solution be to have package.* files that allow the user to specify FEATURES, CFLAGS, and CXXFLAGS per package? (Of course, I do realize that it's the lack of such files that lead vapier to propose his solution, which is rather more convenient for one-off builds.) -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76
pgp5cgkviFCsQ.pgp
Description: PGP signature
