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 |