1 |
On Mon, Dec 1, 2008 at 3:14 PM, Maciej Mrozowski <reavertm@××××××.fm> wrote: |
2 |
> On Monday 01 of December 2008 22:51:57 Ciaran McCreesh wrote: |
3 |
> |
4 |
>> Experience, manpower, the ability to try out potential enhancements |
5 |
>> rapidly, a long track record of getting it right and the growing |
6 |
>> recognition that most people doing package manager work for Gentoo |
7 |
>> aren't doing it with Portage. |
8 |
> |
9 |
> While of course I agree that any input from 'outside' is welcome and valuable, |
10 |
> yet to get things done, in my opinion the final decision should not be blocked |
11 |
> by from any alternative package manager and some policies should be enforced. |
12 |
> |
13 |
> But on topic, what's a counter proposal for my idea then? |
14 |
|
15 |
<mean hat> |
16 |
|
17 |
You asked, so the counter proposal is to *do nothing*. |
18 |
|
19 |
<very mean generic rant hat on> |
20 |
|
21 |
Ideas (even good ones) don't always get implemented. |
22 |
|
23 |
Sometimes that just isn't the direction the maintainers want to take |
24 |
the project. |
25 |
Sometimes it is harder to implement than most people realize. |
26 |
Sometimes suggested implementations are just a hack and a bad idea all around. |
27 |
|
28 |
I think starting with an implementation may have been a bad starting move. |
29 |
|
30 |
Start with what you want to accomplish: |
31 |
- Get feedback on whether this is useful or not. |
32 |
- Get feedback on other features that may be available. |
33 |
- Get feedback on how some folks would accomplish this. |
34 |
|
35 |
"I want to be able to turn debug builds on or off on a per-package |
36 |
basis. Debug builds entail both debugging symbols, split-debug, debug |
37 |
CFLAGS and debug LDFLAGS." |
38 |
|
39 |
Is that a fair summary of your request? |
40 |
|
41 |
I am unsure how much you actually care about how each package manager |
42 |
implements this feature (or if anyone implements it but portage, or |
43 |
paludis, or whatever the majority of the KDE users are using). |
44 |
|
45 |
I'm also unsure how useful this is when say, some part of KDE links |
46 |
against libfoo and KDE is built with debug symbols but libfoo is not. |
47 |
Is that really useful? Are users actually asking for this proposed |
48 |
feature or do you just think they want it? Do you have any data to |
49 |
back up why someone should implement this feature (mailing list posts, |
50 |
forums threads, etc..) |
51 |
|
52 |
Certainly for portage per-package features are possible with a minor |
53 |
patch (to read the custom settings from your config and to inject the |
54 |
FEATURES variables into the per-package config when necessary). The |
55 |
problem that has been stated in the past is that FEATURES were not |
56 |
designed to be used in that manner (per-package). |
57 |
|
58 |
We could design an separate system that let you define per-package |
59 |
'things' and use these 'things' to trigger debug builds (completely |
60 |
outside of FEATURES, leaving them alone). FEATURES were in fact |
61 |
specific features of portage that you want 'on' or 'off' |
62 |
(metadata-transfer, parallel-fetch, userfetch, unmerge-orphans, |
63 |
etc...) These are examples of things you would not turn off |
64 |
per-ebuild. |
65 |
|
66 |
But the question is always 'is it really worth it' and can you get |
67 |
someone to do it. |
68 |
Sometimes, doing nothing is better than doing something badly. |
69 |
|
70 |
<endrant> |
71 |
|
72 |
-Alec |
73 |
|
74 |
> Quick search in archives gave me some results I don't particularly like, like |
75 |
> the idea with /etc/portage/packages.cflags and /etc/portage/package.env, and |
76 |
> they have been dropped for similar reasons - as the former needs special |
77 |
> parsing instead just sourcing the script (the problem is that someone needs to |
78 |
> implement this - this is usually the problem, especially in pure volunteer |
79 |
> projects like Gentoo), the latter looks a bit messy to me. /etc/portage/env |
80 |
> would be the best approach when made officially supported (recently it looks |
81 |
> like /etc/portage/env is sourced multiple times and that should be fixed, for |
82 |
> convenience, just in case user wants to put: |
83 |
> CFLAGS="-O0 -ggdb" |
84 |
> CXXFLAGS="${CFLAGS}" |
85 |
> FEATURES="${FEATURES} nostrip" |
86 |
> (or even USE="${USE} debug") |
87 |
> actually /etc/portage/env could easily replace package.keywords and |
88 |
> package.use as well and introduce replacement for meybe-proposed-sometime |
89 |
> package.features - I wonder whether it's been discussed already. |
90 |
|
91 |
Not without causing a bunch of pain in figuring out the inheriting |
92 |
order of stack USE variables. |
93 |
|
94 |
> |
95 |
> -- |
96 |
> regards |
97 |
> MM |
98 |
> |