Gentoo Archives: gentoo-dev

From: Grant Goodyear <g2boojum@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] fix binary debug support, part elevenity billion + 1
Date: Wed, 07 Jun 2006 19:39:09
Message-Id: 20060607193157.GA15308@dst.grantgoodyear.org
In Reply to: Re: [gentoo-dev] fix binary debug support, part elevenity billion + 1 by Zac Medico
1 Zac Medico wrote: [Wed Jun 07 2006, 01:30:38PM CDT]
2 > Mike Frysinger wrote:
3 > > this is a *huge* con ... developers are lazy, *i'm* lazy ... i
4 > > certainly do not want to go through every single package i maintain
5 > > and add 'debug-build' to IUSE or 'inherit some-new-eclass'
6 >
7 > Sometimes it takes a little extra work to do things right, but
8 > hopefully it will pay off in the long run. A poor design decision
9 > made now can haunt us for years to come.
10
11 A "little extra work"? I'm pretty sure that such an eclass would be
12 required for better than half the tree (every package that contains some
13 C or C++). If almost everybody has to add the same piece of
14 boilerplate to their ebuilds, then perhaps a sane package manager should
15 be able to figure out what to do without the boilerplate. That
16 rationale seems especially true in this case, where nostrip and
17 debugging flags will do no harm for packages that aren't C or C++.
18
19 > > if the large majority of packages are going to be taking advantage of a
20 > > feature, isnt the logical thing to opt everyone in rather than forcing the
21 > > majority to opt themselves in ?
22 >
23 > It really depends on the pros/cons applying something on a *global*
24 > scale, like you propose. A package manager (such as portage) will
25 > never be able to make debug-build decisions that work well for *every*
26 > ebuild. That's why it's better for ebuilds to make those decisions
27 > themselves (with the help of eclasses).
28
29 I would think that your argument would depend on the probability of a
30 package being an exception to the general rule. How many packages
31 actually fail to do what is expected when compiled with -g and nostrip
32 (noting that those cases without binaries to strip don't count)?
33 Unless that percentage is significant, then I would think that a simple
34 solution that handles the common case is a very good thing.
35
36 Wouldn't the "simple" solution be to have package.* files that allow the
37 user to specify FEATURES, CFLAGS, and CXXFLAGS per package? (Of course,
38 I do realize that it's the lack of such files that lead vapier to
39 propose his solution, which is rather more convenient for one-off
40 builds.)
41
42 -g2boojum-
43 --
44 Grant Goodyear
45 Gentoo Developer
46 g2boojum@g.o
47 http://www.gentoo.org/~g2boojum
48 GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76

Replies