FEATURES use or misuse?
 

Hi there,

a while ago Thilo Bangert spent quite some time on filing lots of bugs. While
I appreciate such QA efforts I don't agree with those bugs at all.

All of these bugs were for the use of the FEATURES variable in ebuilds, which
is a very convenient thing to work around issues.
For example known failures with FEATURE="distcc" or funky things like test
failures with FEATURES="userpriv" and so on. All other methods of expressing
that are much more verbose and inherently sucky.

One example of such a bug is https://bugs.gentoo.org/show_bug.cgi?id=278960
for those too lazy to search.

To quote:
"FEATURES is a portage specific package manager configuration variable not
specified in PMS and cannot reliably be used in ebuilds or eclasses."

Well then, I suggest we finally start documenting reality and fix PMS. The use
of the FEATURES variable, while it has been there for ... uhm ... as long as I
can think back, actually :), should not be randomly suppressed.

So ... what's your opinion? Should we do things as they are correct, or as
they are specified in PMS? ( /me points at bash 3.0 )

Take care,

Patrick

FEATURES use or misuse?
 

Patrick Lauer wrote:
> Hi there,
>
> a while ago Thilo Bangert spent quite some time on filing lots of bugs. While
> I appreciate such QA efforts I don't agree with those bugs at all.
>
> All of these bugs were for the use of the FEATURES variable in ebuilds, which
> is a very convenient thing to work around issues.
> For example known failures with FEATURE="distcc" or funky things like test
> failures with FEATURES="userpriv" and so on. All other methods of expressing
> that are much more verbose and inherently sucky.

What other methods are there?


> One example of such a bug is https://bugs.gentoo.org/show_bug.cgi?id=278960
> for those too lazy to search.

For that very case I remember that "test" is a global use flag as well
and that therefore at least

if hasq test ${FEATURES} ; then
[..]
fi

has a cleaner use-flag-based equivalent.

# euse -i test
global use flags (searching: test)
************************************************** **********
[- ] test - Workaround to pull in packages needed to run with
FEATURES=test. Portage-2.1.2 handles this internally,
so don't set it in make.conf/package.use anymore


> 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.


> Well then, I suggest we finally start documenting reality and fix PMS. The use
> of the FEATURES variable, while it has been there for ... uhm ... as long as I
> can think back, actually :), should not be randomly suppressed.
>
> So ... what's your opinion? Should we do things as they are correct, or as
> they are specified in PMS? ( /me points at bash 3.0 )

My opinion is: please stop dissing PMS, it doesn't help anybody.
I have requested that from you before.

Would a patch for the next EAPI theoretically impossible?



Sebastian

FEATURES use or misuse?
 

On Tuesday 03 November 2009 18:27:46 Sebastian Pipping wrote:
> Patrick Lauer wrote:
> > Hi there,
> >
> > a while ago Thilo Bangert spent quite some time on filing lots of bugs.
> > While I appreciate such QA efforts I don't agree with those bugs at all.
> >
> > All of these bugs were for the use of the FEATURES variable in ebuilds,
> > which is a very convenient thing to work around issues.
> > For example known failures with FEATURE="distcc" or funky things like
> > test failures with FEATURES="userpriv" and so on. All other methods of
> > expressing that are much more verbose and inherently sucky.
>
> What other methods are there?

For distcc, you could try some random things like checking the CC variable or
such. All inherently unreliable methods to guess if the FEATURE variable
contains a certain string.

Userpriv I've seen the funny idea to check if UID=0 and such.

I'd guess for every FEATURE there's a similarly confused method to guess if it
is enabled or disabled, instead of just checking the friggin variable.

>
> > One example of such a bug is
> > https://bugs.gentoo.org/show_bug.cgi?id=278960 for those too lazy to
> > search.
>
> For that very case I remember that "test" is a global use flag as well
> and that therefore at least
>
> if hasq test ${FEATURES} ; then
> [..]
> fi
>
> has a cleaner use-flag-based equivalent.
>
> # euse -i test
> global use flags (searching: test)
> ************************************************** **********
> [- ] test - Workaround to pull in packages needed to run with
> FEATURES=test. Portage-2.1.2 handles this internally,
> so don't set it in make.conf/package.use anymore

That's a creative way to use a side-effect to check. Assumes that the package
uses that useflag though, what about the case where you want to conditionally
change a file (or maybe delete it or whatever) in src_prepare when
FEATURES="test" is set, but USE="test" is not needed?

In short, stop complexifying things.

>
> > 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 :)

> My opinion is: please stop dissing PMS, it doesn't help anybody.
> I have requested that from you before.
It's still broken.
It doesn't document reality.
It's not useful as an implementation guideline or as a reference how to do
things. In short, it sucks badly. And all my attempts to get it fixed have
been deflected, so I'll keep ridiculing it until it stops being a failwhale.

After all I'm here to participate in the bestest distro ever, so we deserve
correct and consistent documentation.

> Would a patch for the next EAPI theoretically impossible?
I absolutely fail to see how that helps the current situation.
EAPI is not the right answer to every question. :)


Have fun,

Patrick

FEATURES use or misuse?
 

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).

> > > 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.

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.

> 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, 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.

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.

--
Ciaran McCreesh

FEATURES use or misuse?
 

> To quote:
> "FEATURES is a portage specific package manager configuration
> variable not specified in PMS and cannot reliably be used in ebuilds
> or eclasses."

For distcc & ccache, let me quote ebuild.sh code:

if hasq distcc $FEATURES ; then
export PATH="/usr/lib/distcc/bin:$PATH"
[[ -n $DISTCC_LOG ]] && addwrite "${DISTCC_LOG%/*}"
fi

if hasq ccache $FEATURES ; then
export PATH="/usr/lib/ccache/bin:$PATH"
[...]

Do you want an example how to mimic this with portage without having
neither distcc nor ccache in FEATURES?
Even with portage, checking the FEATURES variable isn't reliable. If
you do not want to fix the real bugs and check/disable distcc/ccache
for any reason, then check PATH.

If you want to keep this simple, write an eclass providing functions
for disabling/checking these features.

> Well then, I suggest we finally start documenting reality and fix
> PMS. The use of the FEATURES variable, while it has been there
> for ... uhm ... as long as I can think back, actually :), should not
> be randomly suppressed.

If you want to fix PMS, then send a patch rephrasing it to explain why
it isn't correct to check FEATURES in some cases. On the other hand, as
its name implies, PMS is a spec, not a documentation on why every
single choice has been made.

> So ... what's your opinion? Should we do things as they are correct,
> or as they are specified in PMS?

PMS may have some flaws, but not these, sorry.

> ( /me points at bash 3.0 )

Ever thought about backward compatibility and keeping a sane upgrade
path? Because that's exactly what this EAPI & PMS debate is all about
IMHO.


Regards,

Alexis.

FEATURES use or misuse?
 

On Tuesday 03 November 2009 22:26:24 Alexis Ballier wrote:
> > To quote:
> > "FEATURES is a portage specific package manager configuration
> > variable not specified in PMS and cannot reliably be used in ebuilds
> > or eclasses."
>
> For distcc & ccache, let me quote ebuild.sh code:
>
> if hasq distcc $FEATURES ; then
> export PATH="/usr/lib/distcc/bin:$PATH"
> [[ -n $DISTCC_LOG ]] && addwrite "${DISTCC_LOG%/*}"
> fi
>
> if hasq ccache $FEATURES ; then
> export PATH="/usr/lib/ccache/bin:$PATH"
> [...]
>
> Do you want an example how to mimic this with portage without having
> neither distcc nor ccache in FEATURES?
> Even with portage, checking the FEATURES variable isn't reliable. If
> you do not want to fix the real bugs and check/disable distcc/ccache
> for any reason, then check PATH.
Well, if a user wants to shoot himself hard enough in the foot he (or she, or
it) can do that. But in the general case we should allow silly assumptions,
one of them being that if a user sets FEATURES="distcc" that he wants to use
distcc and will use the portage mechanisms to enable it. The assumption that
the FEATURE variable actually controls the behaviour of such features seems
like a good idea to me, almost as good as digital watches.

> If you want to keep this simple, write an eclass providing functions
> for disabling/checking these features.
Wow, that's a nice way to make things complex :)
(and why not let the package manager manage such things?)

> > Well then, I suggest we finally start documenting reality and fix
> > PMS. The use of the FEATURES variable, while it has been there
> > for ... uhm ... as long as I can think back, actually :), should not
> > be randomly suppressed.
>
> If you want to fix PMS, then send a patch
I tried, and as I've been saying for a long time they get rejected.
Funnily not by any dev but by some random user, but who cares :)
With the current attitude PMS will be marginalized and worked around by
people. Reality is what you perceive.

> rephrasing it to explain why
> it isn't correct to check FEATURES in some cases. On the other hand, as
> its name implies, PMS is a spec, not a documentation on why every
> single choice has been made.
It's not a spec. Any engineer who has been involved in the spec creation or
update process will gladly show you where it fails (for example not
documenting, on purpose, some bits instead of documenting them with the note
that this is nonstandard behaviour. A real specification will document such
errata because then anyone working with it knows the potential issues ...)


> > ( /me points at bash 3.0 )
>
> Ever thought about backward compatibility and keeping a sane upgrade
> path? Because that's exactly what this EAPI & PMS debate is all about
> IMHO.
Well, I don't want to be rude to you. But please, try using the KDE eclass
with bash 3.0. Or maybe, just for fun (yeah, I know) portage.

Please do it and then tell me how forcing bash 3.2, then documenting the need
for bash 3.0, is in any way sane or consistent.

We broke backwards compatibility about a year ago. Since then we've collected
so many bash-3.0-incompatible bits that a migration back is technically
possible, but practically no longer an acceptable solution (And trying to
force it will make you lots of new "friends"). Your objections come a year to
late. Now we have to accept reality and decide how to live with it.

Calling EAPI is ... well ... I can't even think of a place to start to explain
how wrong it is. How on earth are you going to parse an eclass that supports
multiple EAPIs where one EAPI were to support features of bash 4?
The only way to do it would be to force bash 4 on all lower EAPIs, or make
per-EAPI eclasses, or forbid use of new bash features in eclasses.
All horrible ways to avoid fixing the problem. All workaroundable by just
accepting things as they are.

Sometimes EAPI is not a viable solution to a problem.

Take care,

Patrick

FEATURES use or misuse?
 

On Tue, 3 Nov 2009 23:04:58 +0100
Patrick Lauer <patrick@gentoo.org> wrote:
> > If you want to fix PMS, then send a patch
> I tried, and as I've been saying for a long time they get rejected.

Yes, let's look at the patches that you sent that were rejected:

The first was one where you asked the PMS team to make a change that
goes directly against a Council decision, and that the PMS team does
not have the authority to accept on its own. You were told to bring
the issue to gentoo-dev@ for further attention. You never did.

The second patch you sent:

* incorrectly removed as "no content" two sentences that had specific
and necessary meaning.

* didn't apply against any version of PMS except your much-modified
local version, and that didn't make sense when applied to version of
PMS that anyone else had.

Again, no updated patch was sent.

The third patch you sent had a number of small issues and could have
been improved. You did not send an updated patch with those issues
fixed.

> Funnily not by any dev but by some random user, but who cares :)

Everyone on the PMS mailing list is more than welcome to do patch
reviews. The more eyes we have looking at things the better. Policy is
not to apply patches until everyone is happy with them; objections are
considered on their merits, not on their author.

Every other person who has had people comment upon a patch they
submitted has either addressed the issues and submitted an updated
patch, or explained why they feel the patch is correct as-is.

Every other person who has submitted a patch has worked with all the
reviewers to reach a conclusion that is acceptable to all involved.

Every other person has an ultimate patch acceptance rate of at least
98%. You are the *only* person to have had patches rejected where the
submitter did not agree with the rejection.

--
Ciaran McCreesh

FEATURES use or misuse?
 

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

FEATURES use or misuse?
 

On Tuesday 03 November 2009 15:48:03 Patrick Lauer wrote:
> To quote:
> "FEATURES is a portage specific package manager configuration variable not
> specified in PMS and cannot reliably be used in ebuilds or eclasses."

This has been the Portage team's position for years, since long before there
were PMS and other package managers. See
http://bugs.gentoo.org/show_bug.cgi?id=82513#c16 for example.

FEATURES use or misuse?
 

On Tue, 3 Nov 2009 23:28:57 +0100
Patrick Lauer <patrick@gentoo.org> wrote:

> And then why bother when the tree doesn't reflect PMS.

Maybe if some people would stop ignoring PMS on whim because they don't agree
with something in it this wouldn't be the case.

Like, when does this end? Whenever there's a policy you don't agree with,
you do whatever you want? And it's the policy that's the problem?

I don't get it.

Anyways, this has nothing to do with PMS. Using FEATURES in the tree was
frowned upon long before it even existed. The fact that it wasn't documented
as such outside of mailing lists and bug reports is the real bug.


--
fonts, Character is what you are in the dark.
gcc-porting,
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662