On Mon, Dec 1, 2008 at 3:14 PM, Maciej Mrozowski <[EMAIL PROTECTED]> wrote:
> On Monday 01 of December 2008 22:51:57 Ciaran McCreesh wrote:
>
>> Experience, manpower, the ability to try out potential enhancements
>> rapidly, a long track record of getting it right and the growing
>> recognition that most people doing package manager work for Gentoo
>> aren't doing it with Portage.
>
> While of course I agree that any input from 'outside' is welcome and valuable,
> yet to get things done, in my opinion the final decision should not be blocked
> by from any alternative package manager and some policies should be enforced.
>
> But on topic, what's a counter proposal for my idea then?
<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?
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..)
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>
-Alec
> Quick search in archives gave me some results I don't particularly like, like
> the idea with /etc/portage/packages.cflags and /etc/portage/package.env, and
> they have been dropped for similar reasons - as the former needs special
> parsing instead just sourcing the script (the problem is that someone needs to
> implement this - this is usually the problem, especially in pure volunteer
> projects like Gentoo), the latter looks a bit messy to me. /etc/portage/env
> would be the best approach when made officially supported (recently it looks
> like /etc/portage/env is sourced multiple times and that should be fixed, for
> convenience, just in case user wants to put:
> CFLAGS="-O0 -ggdb"
> CXXFLAGS="${CFLAGS}"
> FEATURES="${FEATURES} nostrip"
> (or even USE="${USE} debug")
> actually /etc/portage/env could easily replace package.keywords and
> package.use as well and introduce replacement for meybe-proposed-sometime
> package.features - I wonder whether it's been discussed already.
Not without causing a bunch of pain in figuring out the inheriting
order of stack USE variables.
>
> --
> regards
> MM
>
