FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 11-03-2009, 11:33 PM
Sebastian Pipping
 
Default FEATURES use or misuse?

Patrick Lauer wrote:
> 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.

I find restricting the eclass to Bash 3 is a natural, maintainable
approach to this. How would "fixing he problem" work from your perspective?


> All workaroundable by just
> accepting things as they are.

What do you mean by "accepting things as they are"?
You have been talking of "accepting reality" repeatedly and I'm left
wondering what you actually mean by that. I especially fail to see who
is trying to conceal(?) reality and reality about what.



Sebastian
 
Old 11-04-2009, 12:31 AM
Duncan
 
Default FEATURES use or misuse?

David Leverton posted on Tue, 03 Nov 2009 23:04:33 +0000 as excerpted:

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

Indeed, that comment is from 2005, but I've been around since 2004 and
remember no other position on FEATURES, ever. There are others who
predate me. Idle question, when was FEATURES introduced as a portage
variable?

Of course, one way to end the debate would be for portage to unset the
variable before calling ebuild.sh, on environment pollution grounds...
Given the history of (ab)use, there'd be solid reason to do that. Maybe
I should file a bug...

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
 
Old 11-04-2009, 07:26 AM
Patrick Lauer
 
Default FEATURES use or misuse?

On Wednesday 04 November 2009 01:33:23 Sebastian Pipping wrote:
> Patrick Lauer wrote:
> > 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.
>
> I find restricting the eclass to Bash 3 is a natural, maintainable
> approach to this. How would "fixing he problem" work from your
> perspective?
It doesn't
You can't use the "new" features in the "old" eclass, even with conditionals
separating the execution paths. Which means you'd have to either not use them
(which makes me wonder why we allow features when they can't be used).
Or you clone the eclass and now maintain the code in two places (wheee, bad
engineering!)

So we end up with a bad solution either way. There are some clean options, but
they tend to be a bit more complex. For example globally forcing minimum
versions (which makes upgrade paths a bit more interesting).

>
> > All workaroundable by just
> > accepting things as they are.
>
> What do you mean by "accepting things as they are"?

People have been doing things (in this case using bash 3.2 features) for a
long time (about a year now). Even when some people warned about the impact
noone cared.

So more and more these "illegal" features get used, and as there are no
sanctions for it (not even from QA!) they are accepted as allowed.

Fast forward and you have an informal standard (using += in ebuilds is ok)
that is agreed on by everyone. Yes, everyone, because when people pointed out
that it was a Bad Thing there was no reaction, no opposition, nothing.

So the Gentoo developer community agreed on it. The only thing not reflecting
that agreement is PMS. So we fix it.

Same with FEATURES variable. Been used for the last few years. Works.
Most reliable way to do a few things if you assume that users don't actively
try to break things. And instead of properly documenting it we pretend it
never happened?


> You have been talking of "accepting reality" repeatedly and I'm left
> wondering what you actually mean by that. I especially fail to see who
> is trying to conceal(?) reality and reality about what.
Ok,

from stable portage ebuilds:
RDEPEND=" [snip]
>=app-shells/bash-3.2_p17

from KDE eclass:
RESTRICT+=" test"

gentoo-x86/app-shells/bash $ ls -1 *.ebuild
bash-3.1_p17.ebuild
bash-3.2_p39.ebuild
bash-3.2_p48-r1.ebuild
bash-3.2_p48.ebuild
bash-4.0_p28.ebuild
bash-4.0_p33.ebuild
bash-4.0_p35.ebuild

So we can either dance around all day and pretend bash 3.0 still has any
relevance, or we stop the nonsense and tolerate reality as it is.

We can also pretend FEATURES never served a purpose and doesn't fix any
issues, then spend lots of time workarounding around working solutions because
we just declared them illegal.

I don't know how much time you have and what your priorities are, but I'm not
going to care about such a waste of time, and it goes very low on my list of
priorities. If there's a decision on this I doubt most devs will care much, so
anyone wanting to have the FEATURES use removed will end up having to do it
himself, against the resistance of package maintainers (don't touch my package
etc. etc.)

Have fun,

Patrick
 
Old 11-04-2009, 07:26 AM
Patrick Lauer
 
Default FEATURES use or misuse?

On Wednesday 04 November 2009 01:11:39 Ryan Hill wrote:
> 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.

Well, we have at least one prior discussion and a year of precedent on the
bash 3.0 / 3.2 thing. Since there were no sanctions for doing it, there's no
way to break things with it (because you have a recent enough bash guaranteed)
and it is very convenient people started using it.

After a year of use (and getting used more and more) I just don't see how any
sane person can think about forbidding it NOW. It's too late. We've moved on.
You missed your chance.

FEATURES has been used in ebuilds for a loooong time. People were happy with
it. The only reason it was not properly documented in PMS was because the
authors didn't agree with it. That's not how you do a standard, but then it
never was about documenting reality. Now PMS has this hole in it, and instead
of (1) documenting current behaviour and (2) agreeing on a standard behaviour
while (3) keeping the historical errata documented ... well, it's kinda, look
over there ... *runs away*
Not a way to discuss or write a standard, also making things complicated when
there are known easy ways to fix it.
>
> 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?
>
Well, if everyone else freely ignores it and pointing out that people
violating the policy has no response I'll consider that policy inactive.

If the Gentoo developers vote with their feet I'm not going to pretend they
didn't. What you can do then is document what just happened ... maybe ...
optionally?


> 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.
>
And that usage was tolerated for >2 years. I still don't see what's bad about
using things as they are, but if people now decide that we need to do complex
dances instead of fixing things I'll just grab a camera and tape it instead of
complaining. Life is too short to get worked up about such things
 
Old 11-04-2009, 09:12 PM
Peter Hjalmarsson
 
Default FEATURES use or misuse?

tis 2009-11-03 klockan 16:48 +0100 skrev Patrick Lauer:
> Hi there,
>
> 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.

I ask myself if what we really want is many different and strange
approaches to handle FEATURES?
Would it not be better to actually expand some eclasses to be able to
say something about your build environment?
I mean where the checks for "userpriv" is needed also prefix will fail,
because AFAIK it can be used to build and install programs in an
non-root environment? Or if you just test an ebuild and runs it as your
user? So would it not just be better to have a check for which privs the
user has so it covers more fields?
For "ccache" and for "distcc" would it not be better to expand
toolchain-funcs so you can have a function like "tc-getCC" from which
you can get that sort of information?

Also if the ebuilds does not already have a comment about it, do not
forget to comment on why these checks are there, and why they are a must
(i.e. a broken buildsystem should be fixed, not worked around - while
tests that are designed to run as root should not be run as a user even
if in the best of worlds all testsuits should test and skip those tests
themselves).
I would not like to see a new kind of hell where when something is
broken it is not fixed properly, but in a strange ways worked around in
ways that does not always work.
qemu and kvm is good examples on how NOT to do this these with regards
to hardened.

qemu (which kvm apparently has used as a template) has a broken build
system (it does not link with CFLAGS, only LDFLAGS, which is something
that also the gcc devs say you should not if you want a predictable
result), and it also invokes filter-flags at the wrong place in the
ebuild (hint: int should be invoked before the command that sets the
CFLAGS, in this case ./configure and not after like in these ebuilds).
Instead it has some strange logic to unset/change the GCC_SPECS which if
it ever worked certainly does not anymore (bugs filed for both, qemu bug
is really old, but very noisy, bug for kvm has been open for about an
week which the qemu maintainer may want to check out, with a clean patch
of one added sed a move of filter-flags and the removal of the whole
src_compile block to make the ebuild install something which (in case of
qemu) actually build, and does not segfault as soon as it uses a bit
softmmu).
 
Old 11-05-2009, 12:36 AM
Ryan Hill
 
Default FEATURES use or misuse?

On Wed, 4 Nov 2009 09:26:10 +0100
Patrick Lauer <patrick@gentoo.org> wrote:

> On Wednesday 04 November 2009 01:11:39 Ryan Hill wrote:
> > 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.
>
> Well, we have at least one prior discussion and a year of precedent on the
> bash 3.0 / 3.2 thing. Since there were no sanctions for doing it, there's no
> way to break things with it (because you have a recent enough bash guaranteed)
> and it is very convenient people started using it.
>
> After a year of use (and getting used more and more) I just don't see how any
> sane person can think about forbidding it NOW. It's too late. We've moved on.
> You missed your chance.

Yes, I think we did. I think any damage that could have been done by people
ignoring policies about sticking to bash 3.0 has been done, and enforcing it
now would be pointless.

That's not to say though that it shouldn't have been enforced. If anything,
I think this is a textbook example of the kind of corner we paint ourselves
into when people do whatever the fuck they feel like. In this particular
case, it seems, no real harm was done except some small amount of backwards
compatibility was thrown out the window. What happens next time? I'm
surprised you're using this as an example to support your case because if
anything it warns me that we need to be more careful in the future.

> The only reason it was not properly documented in PMS was because the
> authors didn't agree with it.

Bullshit. It wasn't documented in PMS because PMS doesn't document user
configuration, because PMS shouldn't document user configuration. User
configuration is implementation specific. Do you not realize what a pain in
the ass it would be if we had to do an EAPI bump to slightly change the
semantics of "userpriv" or to change the enabled defaults, not to mention
change any of the environment variables portage uses for configuration?
Making these things independent of the specification allows the package
manager the freedom it needs to make the changes it needs to in order to
continue improving, and frankly, allows other implementations to be something
other than simple portage clones.

And you're still ignoring the fact that this has nothing to do with PMS. You
have a core portage dev on record, saying "FEATURES are not supposed to have
an effect on the package itself, just how portage handles the package.
Packages behaving differently on certain FEATURES settings are considered
broken by me" back in 2005, before PMS was even a glimmer in an ex-gentoo
dev's eye.

> Well, if everyone else freely ignores it and pointing out that people
> violating the policy has no response I'll consider that policy inactive.

Then we obviously need more people laying the smack down.


--
fonts, Character is what you are in the dark.
gcc-porting,
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
 
Old 11-05-2009, 04:04 AM
Brian Harring
 
Default FEATURES use or misuse?

On Wed, Nov 04, 2009 at 11:12:05PM +0100, Peter Hjalmarsson wrote:
> tis 2009-11-03 klockan 16:48 +0100 skrev Patrick Lauer:
> > Hi there,
> >
> > 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.
>
> I ask myself if what we really want is many different and strange
> approaches to handle FEATURES?
> Would it not be better to actually expand some eclasses to be able to
> say something about your build environment?

This is a *really* bad approach- pkgcore/paludis have supported
standalone repositories basically from their inception, portage (via
repos.conf) has developed equivalent support, and from the looks of it
is moving towards such capabilities.

What this means is that eclasses aren't automatically mashed together
across all trees and shared. Meaning each repository would have to
carry those eclasses, or require that they always be slaved against a
specific repository carrying said eclasses (again, bad mojo).

The code duplication there is annoying, but the potential range of
screwups this can lead to is even worse. Further, via proper
environment saving/restoration for installed pkgs/binpkgs, this means
that one screwed up FEATURES detection (or that things have changed
since then and a new check is required) lives on forever, no
possibility of being updated/fixed in the env dump.

Shorter version, eclasses are a fun idea at first until you dig in and
realize they'll blow your leg off for things like this.

If it's any consolation, I proposed moving large chunks of eapi0
(prior to eapi existing) into the tree- the idea died off for the same
reasons your "FEATURE awareness in eclasses" must die off.

~harring
 

Thread Tools




All times are GMT. The time now is 08:11 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org