From: Patrick Lauer <patrick@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] FEATURES use or misuse?
Date: Tue, 3 Nov 2009 23:28:57 +0100 [thread overview]
Message-ID: <200911032328.57477.patrick@gentoo.org> (raw)
In-Reply-To: <20091103205827.339c1613@snowcone>
On Tuesday 03 November 2009 21:58:27 Ciaran McCreesh wrote:
> On Tue, 3 Nov 2009 21:36:18 +0100
>
> Patrick Lauer <patrick@gentoo.org> wrote:
> > Userpriv I've seen the funny idea to check if UID=0 and such.
>
> Yes, and that 'funny idea' has the added advantage of working even if
> userpriv is in FEATURES but not actually enabled (yes, that can happen).
>
I would consider that a bug. Maybe fixing that bug is easier than
workarounding it?
> > > > To quote:
> > > > "FEATURES is a portage specific package manager configuration
> > > > variable not specified in PMS and cannot reliably be used in
> > > > ebuilds or eclasses."
> > >
> > > Makes sense to me atm.
> >
> > Makes no sense to me, but then I seem to be special :)
>
> PMS doesn't document user configuration. If PMS did document user
> configuration, it would mean that user configuration file formats
> couldn't arbitrarily be changed between package manager versions as
> they are now.
I fail to see which part of "It's a key-value list, like the old windows .ini
files, with comments starting with # allowed" is so specially specific that it
can't be documented. But then I often fail to notice such obvious
obviousities.
> If FEATURES were specified by PMS, Portage wouldn't be able to change
> the meaning of its entries without careful EAPI controls. So far as I'm
> aware, no-one is in favour of introducing such a restriction. There
> are easy alternatives available, and unlike checking FEATURES, those
> alternatives actually work.
That is concentrated nonsense. You're implying that an ebuild setting (EAPI)
can control the package manager configuration. That's so exquisitely backwards
and incoherent that I'm having a hard time taking you serious.
If PMS defined the existance of a FEATURES variable (like, say, CFLAGS) then
the contents of that variable could be arbitrary whitespace-separated strings.
Amazingly CFLAGS is not EAPI-controlled and can take arbitrary values, so
generalizing that amazing functionality to other configuration variables
should be an easy exercise for the advanced reader.
Once that is done it can be specialized to a FEATURES variable, which is
exactly what we expected.
>
> > And all my attempts to get it fixed have been deflected, so I'll keep
> > ridiculing it until it stops being a failwhale.
>
> Patrick, perhaps you would find your efforts more fruitful were you to
> respond to reviews of your patches by fixing the issues raised,
I'm trying to do that. And you might want to not patronize me (especially in
an academic setting that would be terribly rude, on the internet it's just
silly)
The fact that there are a few dozen violations of PMS that are bastardly
expensive to rollback suggests that harmonizing PMS to reality may be the
cheaper method. Trying to bend reality to fit the specification can be an
amusing game, but has a very high chance of failing hard.
> instead
> of using every available opportunity you can find to take pot-shots at
> PMS, close off legitimate bugs as INVALID and generally attempt to make
> life as hard as possible for those for whom PMS matters most.
I do wonder to whom PMS matters.
It didn't matter to the eclass authors that littered them with "bad" bash 3.2
features.
It didn't matter to QA when they were notified of that.
It didn't matter to council back then and is still not high up on their
priority list.
Can it be that the general population of gentoo developers plainly don't care
about PMS? And if we were to assume that were true, why would they do such a
thing?
So many questions. Almost like those TV shows where you can win a million
dollars or a flamingo or a new car.
>
> Of the small number of patches that have ended up being rejected from
> PMS, all but one have been yours, and the one that wasn't was because
> the author had mistranslated a phrase. I'd appreciate it if you would
> stop to consider why this is the case.
>
Well, I've not contributed to PMS (like most people) for a long time. Like
other people I've known that ANY patch I contribute will be denied. Most other
people don't have the curiosity that drives me to try it to prove my theory,
so the number of PMS contributors is amazingly small.
Added to that it's atrocious language. Might have been better if native
english speakers had written it, but beggars can't be choosers. Most people
don't have the stamina to read it, much less find all the spots they'd need to
clean up to have a small bit of functionality improved.
And then why bother when the tree doesn't reflect PMS. It's just futile to
work on a "documentation" that gets the basics wrong. And as soon as you read
up on prior discussions you find these exhausting discussions that go nowhere
... why would any sane person want to spend time working on that? Much more
fun to actually fix bugs or write ebuilds. Or play WoW or whatever.
But I digress. You didn't actually want to have an answer, that was most
likely a rethorical question. Silly me taking things literally.
Anyway, chill out, enjoy Christmas,
Patrick
next prev parent reply other threads:[~2009-11-03 22:29 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-03 15:48 [gentoo-dev] FEATURES use or misuse? Patrick Lauer
2009-11-03 17:27 ` Sebastian Pipping
2009-11-03 20:36 ` Patrick Lauer
2009-11-03 20:58 ` Ciaran McCreesh
2009-11-03 22:28 ` Patrick Lauer [this message]
2009-11-04 0:11 ` [gentoo-dev] " Ryan Hill
2009-11-04 8:26 ` Patrick Lauer
2009-11-05 1:36 ` Ryan Hill
2009-11-05 4:56 ` [gentoo-dev] a pragmatic approach to FEATURES [was FEATURES use or misuse?] Brian Harring
2009-11-05 8:49 ` Thilo Bangert
2009-11-05 9:36 ` Brian Harring
2009-11-08 9:21 ` Thilo Bangert
2009-11-03 21:26 ` [gentoo-dev] FEATURES use or misuse? Alexis Ballier
2009-11-03 22:04 ` Patrick Lauer
2009-11-03 22:26 ` Ciaran McCreesh
2009-11-04 0:33 ` Sebastian Pipping
2009-11-04 8:26 ` Patrick Lauer
2009-11-03 23:04 ` David Leverton
2009-11-04 1:31 ` [gentoo-dev] " Duncan
2009-11-04 22:12 ` Peter Hjalmarsson
2009-11-05 5:04 ` Brian Harring
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200911032328.57477.patrick@gentoo.org \
--to=patrick@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox