Re: [gentoo-dev] Re: debug/release builds extensions/clarification proposal

[Maciej Mrozowski]

On Tuesday 02 of December 2008 10:40:19 Alec Warner wrote:

> <mean hat>
> You asked, so the counter proposal is to *do nothing*.
> <very mean generic rant hat on>
> Ideas (even good ones) don't always get implemented.
>
> Sometimes that just isn't the direction the maintainers want to take
> the project.
> Sometimes it is harder to implement than most people realize.
> Sometimes suggested implementations are just a hack and a bad idea all
> around.
>
> I think starting with an implementation may have been a bad starting move.
>
> Start with what you want to accomplish:
>   - Get feedback on whether this is useful or not.
>   - Get feedback on other features that may be available.
>   - Get feedback on how some folks would accomplish this.
>
> "I want to be able to turn debug builds on or off on a per-package
> basis.  Debug builds entail both debugging symbols, split-debug, debug
> CFLAGS and debug LDFLAGS."
>
> Is that a fair summary of your request?

Yes, precisely. But forget about this proposal, as I stated already it's just 
a workaround for inability to set CFLAGS/LDFLAGS and those two FEATURES per-
package basis in *official* way.

> I am unsure how much you actually care about how each package manager
> implements this feature (or if anyone implements it but portage, or
> paludis, or whatever the majority of the KDE users are using).
>
> I'm also unsure how useful this is when say, some part of KDE links
> against libfoo and KDE is built with debug symbols but libfoo is not.
> Is that really useful?  Are users actually asking for this proposed
> feature or do you just think they want it?  Do you have any data to
> back up why someone should implement this feature (mailing list posts,
> forums threads, etc..)

No, and I'm afraid I cannot provide any single evidence that users actually 
need features like:
- per package cflags/ldflags/features
- per category use flags, accept_keywords, cflags
- or tag clouds instead of hard coded categories
- user-defined packages sets (official)
- multiple portage configurations support to ease building binaries for 
several targets on a same host
- dynamic libraries tracking for safe package upgrade or removal
- real backwards dependencies
- maybe git driven Portage
- automatic kernel modules rebuilding
- mysql split ebuilds

Actually, I'm perfectly certain that users are way more interested in critical 
important aspects of their system like whether HOMEPAGE should be set in 
ebuilds or in metadata.xml :D

Please let me solve your little problem with HOMEPAGE for you...
Package's homepage obviously may be, and actually is - ${PN}-${PV} specific.
That being said it *would* needs to be specified either in every ebuild or as 
someone proposed - in metadata.xml in versioned/tagged way.
And no matter how many searches you run - it may be easy to predict that due 
to lazyness (less probable) or just to avoid copy/paste (copy/paste is bad - 
everyone knows that) - some developers used to put HOMEPAGE in eclasses - 
because it may be used to put in postinst message for some reasons, that being 
said it needs to be in ebuild domain in current implementation.
Mixing XML and bash (ebuild) in general isn't a bad idea but using bothe of 
them seems to be inconsistent - but some trade off needs to be paid sometimes.
When duplicating HOMEPAGE is such a pain for developer (as he needs to type it 
all over again, I agree, it is pain, especially when one need to put some 
things only to please repoman), why not invest some time and develop tools 
that could make it easier - like meta-ebuilds (or ebuild generators) and 
ebuild templates? I've done something like this to autogenerate plasma applet 
live ebuilds from KDE playground on their SVN (it's not yet commited to 
overlay as eclass is not yet ready to fetch/unpack and build packages from 
this location and I haven't got time yet to patch it).
If declaring HOMEPAGE in eclasses troubles you as you need BASH to process it 
properly (it may be pain for non-BASH search tools) and XML may be problematic 
to parse for bash tools - why not create such ebuild generator or 'compiler' - 
that could generate ebuild? Or for example as complete BASH script (no need 
for inherit anything) - and use eclasses ONLY like 'development library'.
This way - every ebuild could be:
- eclass-breakage free (overwriting eclasses don't take place so you are 
certain that user's emerge-problem is not him messing with eclasses - like 
mixing those from other overlays)
- every defined variable is there (no need for 'inherit' lookup) - so that one 
can easily find HOMEPAGE= using every kind of tool (unless it is enclosed with 
some condition - why would anyone need to do that btw?)
- much larger disk space requirements for Portage tree - but that could be 
compensated by for example gzipping every ebuild.
Of  course every problems with dichotomy ebuild vs metadata could be solved by 
some new Portage backend - better suited for queries and storage (maybe some 
relational database).
But so far - the solution in very simple - require HOMEPAGE to be in *every* 
ebuild and make repoman very angry otherwise and don't play with versioned 
metadata because it's waste of your time imho, and it could be invested on 
developing/deploying better backend for example or at least discussing on some 
not needed and never requested features like on the list above (and if 
requested, then probably by some clueless users...).
Glad that I could help.

> Certainly for portage per-package features are possible with a minor
> patch (to read the custom settings from your config and to inject the
> FEATURES variables into the per-package config when necessary).  The
> problem that has been stated in the past is that FEATURES were not
> designed to be used in that manner (per-package).
>
> We could design an separate system that let you define per-package
> 'things' and use these 'things' to trigger debug builds (completely
> outside of FEATURES, leaving them alone).  FEATURES were in fact
> specific features of portage that you want 'on' or 'off'
> (metadata-transfer, parallel-fetch, userfetch, unmerge-orphans,
> etc...)  These are examples of things you would not turn off
> per-ebuild.

> But the question is always 'is it really worth it' and can you get
> someone to do it.
> Sometimes, doing nothing is better than doing something badly.
> <endrant>

Yes, and developers in terms of Portage enhancements seem to be pretty good at 
this. Please don't get me wrong, I admire and respect *every* *singe* *effort* 
put in maintaining packages (maybe because I doing it as well), "wasting time" 
by bug fixing, and making it all alive. I really do.
And I understand that developers are free to spend their own precious free 
time (no sarcasm here) on whatever they want (as it's your time as you 
volunteer) and I would be perfectly fine with that if they wouldn't block the 
progress by miscalculated priorities and only because they have @gentoo.org in 
their email and they are the only ones authorized to introduce changes.

And as as side note - I anyone thinks that Gentoo is his private project and 
users are completely clueless (well, sometimes they are) and they are 
completely irrelevant, I guess the one should acknowledge the existence of 
some materials[1] (and maybe reconsider his further participation otherwise). 
There is some interesting discussion[2] on the forums related to user 
contribution to Gentoo and apart from many valid points by other users, there 
is my proposal[3] that aims to make your life a bit easier.

1. http://www.gentoo.org/foundation/en/#doc_chap2
2. http://forums.gentoo.org/viewtopic-t-702248.html
3. http://forums.gentoo.org/viewtopic-p-5296515.html#5296515

-- 
regards
MM