On Tue, Dec 2, 2008 at 11:19 PM, Maciej Mrozowski <[EMAIL PROTECTED]> wrote:
> 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
Sorry, I can't prioritize email threads ;)
>
> 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.
>
Sweet, fixed!
>> 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.
>
One, I'm not a portage developer, so what I say regarding what goes in
actually doesn't matter, since I can't commit to the repo same as you
;)
Two, If there was some good data around what was the 'correct'
priority for items I would be all for it; but we don't have any good
means to collect it[1].
Three:
Portage is open source; so if a user feels that the developers are
unreliable or mis-prioritize requests they can just implement the
features they want themselves (no "@gentoo.org authorization"
required). If people find the modification useful the author can even
contact the portage team to have their patch included in the official
version. Sadly past experience has shown that very few authors take
this approach in practice; even though to me it is a pillar of open
source awesomeness.
> 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.
I don't think users are clueless. That doesn't mean I will implement
anything they ask of me though; each program I write has specific
goals associated with it (how it is used and what for) and if the
ideas presented are against those goals and the user cannot convince
me that it makes sense for the program to have that functionality then
I will not add that functionality. I may be willing to write a patch
and give it the user for their own use (and they are free to
distribute said patch themselves.)
-Alec
[1] I guess we could crawl the forums for some sort of manual
prioritization, but I'm really looking for like, quarterly user
surveys, that help give us (the developers) an idea about what users
who take the survey say they want from us.
>
> 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
>
