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
signature.asc
Description: This is a digitally signed message part.
