public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Patrick Lauer <patrick@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] FEATURES use or misuse?
Date: Wed, 4 Nov 2009 09:26:05 +0100	[thread overview]
Message-ID: <200911040926.06350.patrick@gentoo.org> (raw)
In-Reply-To: <4AF0CBD3.5050402@gentoo.org>

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





  reply	other threads:[~2009-11-04  8:26 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
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 [this message]
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=200911040926.06350.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