1 |
On Tue, Dec 2, 2008 at 11:19 PM, Maciej Mrozowski <reavertm@××××××.fm> wrote: |
2 |
> On Tuesday 02 of December 2008 10:40:19 Alec Warner wrote: |
3 |
> |
4 |
>> <mean hat> |
5 |
>> You asked, so the counter proposal is to *do nothing*. |
6 |
>> <very mean generic rant hat on> |
7 |
>> Ideas (even good ones) don't always get implemented. |
8 |
>> |
9 |
>> Sometimes that just isn't the direction the maintainers want to take |
10 |
>> the project. |
11 |
>> Sometimes it is harder to implement than most people realize. |
12 |
>> Sometimes suggested implementations are just a hack and a bad idea all |
13 |
>> around. |
14 |
>> |
15 |
>> I think starting with an implementation may have been a bad starting move. |
16 |
>> |
17 |
>> Start with what you want to accomplish: |
18 |
>> - Get feedback on whether this is useful or not. |
19 |
>> - Get feedback on other features that may be available. |
20 |
>> - Get feedback on how some folks would accomplish this. |
21 |
>> |
22 |
>> "I want to be able to turn debug builds on or off on a per-package |
23 |
>> basis. Debug builds entail both debugging symbols, split-debug, debug |
24 |
>> CFLAGS and debug LDFLAGS." |
25 |
>> |
26 |
>> Is that a fair summary of your request? |
27 |
> |
28 |
> Yes, precisely. But forget about this proposal, as I stated already it's just |
29 |
> a workaround for inability to set CFLAGS/LDFLAGS and those two FEATURES per- |
30 |
> package basis in *official* way. |
31 |
> |
32 |
>> I am unsure how much you actually care about how each package manager |
33 |
>> implements this feature (or if anyone implements it but portage, or |
34 |
>> paludis, or whatever the majority of the KDE users are using). |
35 |
>> |
36 |
>> I'm also unsure how useful this is when say, some part of KDE links |
37 |
>> against libfoo and KDE is built with debug symbols but libfoo is not. |
38 |
>> Is that really useful? Are users actually asking for this proposed |
39 |
>> feature or do you just think they want it? Do you have any data to |
40 |
>> back up why someone should implement this feature (mailing list posts, |
41 |
>> forums threads, etc..) |
42 |
> |
43 |
> No, and I'm afraid I cannot provide any single evidence that users actually |
44 |
> need features like: |
45 |
> - per package cflags/ldflags/features |
46 |
> - per category use flags, accept_keywords, cflags |
47 |
> - or tag clouds instead of hard coded categories |
48 |
> - user-defined packages sets (official) |
49 |
> - multiple portage configurations support to ease building binaries for |
50 |
> several targets on a same host |
51 |
> - dynamic libraries tracking for safe package upgrade or removal |
52 |
> - real backwards dependencies |
53 |
> - maybe git driven Portage |
54 |
> - automatic kernel modules rebuilding |
55 |
> - mysql split ebuilds |
56 |
> |
57 |
> Actually, I'm perfectly certain that users are way more interested in critical |
58 |
> important aspects of their system like whether HOMEPAGE should be set in |
59 |
> ebuilds or in metadata.xml :D |
60 |
|
61 |
Sorry, I can't prioritize email threads ;) |
62 |
|
63 |
> |
64 |
> Please let me solve your little problem with HOMEPAGE for you... |
65 |
> Package's homepage obviously may be, and actually is - ${PN}-${PV} specific. |
66 |
> That being said it *would* needs to be specified either in every ebuild or as |
67 |
> someone proposed - in metadata.xml in versioned/tagged way. |
68 |
> And no matter how many searches you run - it may be easy to predict that due |
69 |
> to lazyness (less probable) or just to avoid copy/paste (copy/paste is bad - |
70 |
> everyone knows that) - some developers used to put HOMEPAGE in eclasses - |
71 |
> because it may be used to put in postinst message for some reasons, that being |
72 |
> said it needs to be in ebuild domain in current implementation. |
73 |
> Mixing XML and bash (ebuild) in general isn't a bad idea but using bothe of |
74 |
> them seems to be inconsistent - but some trade off needs to be paid sometimes. |
75 |
> When duplicating HOMEPAGE is such a pain for developer (as he needs to type it |
76 |
> all over again, I agree, it is pain, especially when one need to put some |
77 |
> things only to please repoman), why not invest some time and develop tools |
78 |
> that could make it easier - like meta-ebuilds (or ebuild generators) and |
79 |
> ebuild templates? I've done something like this to autogenerate plasma applet |
80 |
> live ebuilds from KDE playground on their SVN (it's not yet commited to |
81 |
> overlay as eclass is not yet ready to fetch/unpack and build packages from |
82 |
> this location and I haven't got time yet to patch it). |
83 |
> If declaring HOMEPAGE in eclasses troubles you as you need BASH to process it |
84 |
> properly (it may be pain for non-BASH search tools) and XML may be problematic |
85 |
> to parse for bash tools - why not create such ebuild generator or 'compiler' - |
86 |
> that could generate ebuild? Or for example as complete BASH script (no need |
87 |
> for inherit anything) - and use eclasses ONLY like 'development library'. |
88 |
> This way - every ebuild could be: |
89 |
> - eclass-breakage free (overwriting eclasses don't take place so you are |
90 |
> certain that user's emerge-problem is not him messing with eclasses - like |
91 |
> mixing those from other overlays) |
92 |
> - every defined variable is there (no need for 'inherit' lookup) - so that one |
93 |
> can easily find HOMEPAGE= using every kind of tool (unless it is enclosed with |
94 |
> some condition - why would anyone need to do that btw?) |
95 |
> - much larger disk space requirements for Portage tree - but that could be |
96 |
> compensated by for example gzipping every ebuild. |
97 |
> Of course every problems with dichotomy ebuild vs metadata could be solved by |
98 |
> some new Portage backend - better suited for queries and storage (maybe some |
99 |
> relational database). |
100 |
> But so far - the solution in very simple - require HOMEPAGE to be in *every* |
101 |
> ebuild and make repoman very angry otherwise and don't play with versioned |
102 |
> metadata because it's waste of your time imho, and it could be invested on |
103 |
> developing/deploying better backend for example or at least discussing on some |
104 |
> not needed and never requested features like on the list above (and if |
105 |
> requested, then probably by some clueless users...). |
106 |
> Glad that I could help. |
107 |
> |
108 |
|
109 |
Sweet, fixed! |
110 |
|
111 |
>> Certainly for portage per-package features are possible with a minor |
112 |
>> patch (to read the custom settings from your config and to inject the |
113 |
>> FEATURES variables into the per-package config when necessary). The |
114 |
>> problem that has been stated in the past is that FEATURES were not |
115 |
>> designed to be used in that manner (per-package). |
116 |
>> |
117 |
>> We could design an separate system that let you define per-package |
118 |
>> 'things' and use these 'things' to trigger debug builds (completely |
119 |
>> outside of FEATURES, leaving them alone). FEATURES were in fact |
120 |
>> specific features of portage that you want 'on' or 'off' |
121 |
>> (metadata-transfer, parallel-fetch, userfetch, unmerge-orphans, |
122 |
>> etc...) These are examples of things you would not turn off |
123 |
>> per-ebuild. |
124 |
> |
125 |
>> But the question is always 'is it really worth it' and can you get |
126 |
>> someone to do it. |
127 |
>> Sometimes, doing nothing is better than doing something badly. |
128 |
>> <endrant> |
129 |
> |
130 |
> Yes, and developers in terms of Portage enhancements seem to be pretty good at |
131 |
> this. Please don't get me wrong, I admire and respect *every* *singe* *effort* |
132 |
> put in maintaining packages (maybe because I doing it as well), "wasting time" |
133 |
> by bug fixing, and making it all alive. I really do. |
134 |
> And I understand that developers are free to spend their own precious free |
135 |
> time (no sarcasm here) on whatever they want (as it's your time as you |
136 |
> volunteer) and I would be perfectly fine with that if they wouldn't block the |
137 |
> progress by miscalculated priorities and only because they have @gentoo.org in |
138 |
> their email and they are the only ones authorized to introduce changes. |
139 |
> |
140 |
|
141 |
One, I'm not a portage developer, so what I say regarding what goes in |
142 |
actually doesn't matter, since I can't commit to the repo same as you |
143 |
;) |
144 |
|
145 |
Two, If there was some good data around what was the 'correct' |
146 |
priority for items I would be all for it; but we don't have any good |
147 |
means to collect it[1]. |
148 |
|
149 |
Three: |
150 |
Portage is open source; so if a user feels that the developers are |
151 |
unreliable or mis-prioritize requests they can just implement the |
152 |
features they want themselves (no "@gentoo.org authorization" |
153 |
required). If people find the modification useful the author can even |
154 |
contact the portage team to have their patch included in the official |
155 |
version. Sadly past experience has shown that very few authors take |
156 |
this approach in practice; even though to me it is a pillar of open |
157 |
source awesomeness. |
158 |
|
159 |
> And as as side note - I anyone thinks that Gentoo is his private project and |
160 |
> users are completely clueless (well, sometimes they are) and they are |
161 |
> completely irrelevant, I guess the one should acknowledge the existence of |
162 |
> some materials[1] (and maybe reconsider his further participation otherwise). |
163 |
> There is some interesting discussion[2] on the forums related to user |
164 |
> contribution to Gentoo and apart from many valid points by other users, there |
165 |
> is my proposal[3] that aims to make your life a bit easier. |
166 |
|
167 |
I don't think users are clueless. That doesn't mean I will implement |
168 |
anything they ask of me though; each program I write has specific |
169 |
goals associated with it (how it is used and what for) and if the |
170 |
ideas presented are against those goals and the user cannot convince |
171 |
me that it makes sense for the program to have that functionality then |
172 |
I will not add that functionality. I may be willing to write a patch |
173 |
and give it the user for their own use (and they are free to |
174 |
distribute said patch themselves.) |
175 |
|
176 |
-Alec |
177 |
|
178 |
[1] I guess we could crawl the forums for some sort of manual |
179 |
prioritization, but I'm really looking for like, quarterly user |
180 |
surveys, that help give us (the developers) an idea about what users |
181 |
who take the survey say they want from us. |
182 |
|
183 |
> |
184 |
> 1. http://www.gentoo.org/foundation/en/#doc_chap2 |
185 |
> 2. http://forums.gentoo.org/viewtopic-t-702248.html |
186 |
> 3. http://forums.gentoo.org/viewtopic-p-5296515.html#5296515 |
187 |
> |
188 |
> -- |
189 |
> regards |
190 |
> MM |
191 |
> |