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

Attachment: pgp5cgkviFCsQ.pgp
Description: PGP signature

Reply via email to