[gentoo-dev] RFC: Make 10.0 profiles EAPI-2 'compliant'

Andrew D Kirch · External Since: Aug 20, 2009 Posts: 4

Tiziano Müller wrote:
> As you can see currently, most time is needed to implemente the features
> in portage. It therefore doesn't make sense to make the EAPI process
> even faster. On the other hand, I think it would make sense to have a
> separate group developing new EAPIs instead of the council.
>
> Cheers,
> Tiziano

I agree with what's being said here. The previous council ran into a
huge road block with EAPI and GLEP's. I think that EAPI's should be
moved to the Portage herd, and GLEPs assigned as necessary until final
approval or dissent is given by the council. This would hopefully
reduce contention with GLEP's as has happened in the past, and put
EAPI's closer to the devs who will implement them.

Andrew D Kirch
Funtoo.org

Arttu V. · External Since: Jun 28, 2009 Posts: 9

On 8/22/09, Andrew D Kirch <trelane.TakeThisOut@trelane.net> wrote:
> Right, this is called "punishing innovation". It's a hobby of
> bureaucrats everywhere.
> It could also be said to be "punishing excellence".

If it wasn't a sort of a bug (some omission in the original PMS?),
then I suppose this could also be described as The Three 'E's: embrace
(a supposed standard), extend (possibly in an incompatible, hard to
replicate ways), and extinguish (well, harder to do with FLOSS, but
you can probably see where I got these 'e's Wink

). I think that also
Microsoft calls that 'innovation'. Very Happy

Let's just leave this to the Council. These semantic-pedantic "is not,
is too"-discussions with Mr. McCreesh never seem to end as both sides
keep to the logic that if you don't quickly reply to comments which
are "wrong", then your silence means that the other one was "right".
There should be some kind of eternal loop detection for these threads
.... Razz

--
Arttu V.

Chip Parker · External Since: Aug 10, 2009 Posts: 7

On Fri, Aug 21, 2009 at 5:34 PM, Ciaran
McCreesh<ciaran.mccreesh DeleteThis @googlemail.com> wrote:
> On Fri, 21 Aug 2009 17:29:12 -0700
> Chip Parker <infowolfe DeleteThis @gmail.com> wrote:
>> If this feature, which HAD been documented (in bugzilla and
>> commitlogs) prior to the first RFC for PMS
>
> As I've already explained to you on bugzilla, this is untrue. You're
> confusing user configuration with the tree. PMS has nothing to say
> about user configuration, and nothing is being done to take away the
> feature you're concerned about.
>
> --
> Ciaran McCreesh
>

This assertion is not only incorrect but asinine.

build paludis # paludis -q apache
paludis@1250977472: [WARNING e.ebuild.configuration.no_names_cache]
The names_cache key is not set in
'/etc/paludis/repositories/gentoo.conf'. You should read the Paludis
documentation and select an appropriate value.

Unhandled exception:
* In program paludis -q apache:
* When performing query action from command line:
* When handling query 'apache':
* When parsing user package dep spec 'apache':
* When parsing generic package dep spec 'apache':
* When disambiguating package name 'apache':
* When finding all versions in some arbitrary order from packages
matching */apache with filter all matches filtered through all
matches:
* When finding category names containing package 'apache':
* When loading names for virtuals repository:
* When loading virtual packages for repository 'gentoo'
* When loading profiles '/etc/make.profile' for repository 'gentoo':
* When using directory '/etc/make.profile':
* When adding profile directory '/etc/make.profile:
* When handling parent file for profile directory '/etc/make.profile:
* When adding profile directory '/etc/managed-portage/common/pre/make.profile:
* When loading specised use file
'/etc/managed-portage/common/pre/make.profile/package.use:
* In file '/etc/managed-portage/common/pre/make.profile/package.use':
Error reading file: 'Error reading from fd 3: Is a directory'
(paludis::SafeIFStreamError) (paludis::ConfigFileError)

Additionally, I plan to show very soon that PMS is incorrect in its
requirement that profiles/parent includes only relative paths. This
shows that both the PMS spec and your pet package manager are
incapable of supporting behavior that was considered "correct" by
portage prior to your initial RFC.

Chip Parker · External Since: Aug 10, 2009 Posts: 7

On Sat, Aug 22, 2009 at 2:52 PM, Ciaran
McCreesh<ciaran.mccreesh.TakeThisOut@googlemail.com> wrote:
> On Sat, 22 Aug 2009 14:47:44 -0700
> Chip Parker <infowolfe.TakeThisOut@gmail.com> wrote:
>> Â * When loading profiles '/etc/make.profile' for repository 'gentoo':
>
> /etc/make.profile is user configuration, and beyond the scope of PMS.
>
>> Additionally, I plan to show very soon that PMS is incorrect in its
>> requirement that profiles/parent includes only relative paths.
>
> It is impossible to include absolute paths in repository parent files,
> since there is no guaranteed filesystem location for repositories.
>
> This is now the third time I've had to tell you that user configuration
> is not part of PMS. You're contributing substantially to the amount of
> noise on the subject, wasting the time of everyone who has to read your
> posts and respond to them. Kindly stop.
>
> --
> Ciaran McCreesh
>

Since you have a habit of ignoring relevant bits of technical
opposition to some of your more insane schemes, I'll cite *again* the
relevant portion.

'/etc/managed-portage/common/pre/make.profile/package.use:
* In file '/etc/managed-portage/common/pre/make.profile/package.use':
Error reading file: 'Error reading from fd 3: Is a directory'
(paludis::SafeIFStreamError) (paludis::ConfigFileError)

This is the exact same error that I get either when using the portage
compatibility OR paludis with my profile defined in the only
configuration file type where it is allowed to go (on my system
/etc/paludis/repositories/gentoo-portage.conf), as per the paludis
documentation. (http://paludis.pioto.org/configuration/repositories/e.html)

build managed-portage # paludis -q apache
paludis@1250986148: [WARNING portage_environment.dodgy] Use of Portage
configuration files will lead to sub-optimal performance and loss of
functionality. Full support for Portage configuration formats is not
guaranteed; issues should be reported via trac.

Unhandled exception:
<snip repeat of previous email output>
* In file '/etc/managed-portage/common/pre/make.profile/package.use':
Error reading file: 'Error reading from fd 3: Is a directory'
(paludis::SafeIFStreamError) (paludis::ConfigFileError)

So, Ciaran, if your personal reference implementation of PMS fails
miserably when using this methodology, your argument that I won't be
or "am not" affected by your attempt at changing portage is invalid.
If you'd like to test for yourself, I'll be more than happy to tar up
both my /etc/paludis and /etc/managed-portage for you.

If you can show me a DOCUMENTED configuration option for including a
profiles/ directory for use with paludis that is outside of defining
it in a repositories/*.conf file, and it's tested working, I'll gladly
be quiet and go away. Otherwise, I will continue to loudly object to
you attempting to break my systems.

David Leverton · External Since: Apr 01, 2009 Posts: 6

On Sunday 23 August 2009 01:26:24 Chip Parker wrote:
> So, Ciaran, if your personal reference implementation of PMS fails
> miserably when using this methodology, your argument that I won't be
> or "am not" affected by your attempt at changing portage is invalid.
> If you'd like to test for yourself, I'll be more than happy to tar up
> both my /etc/paludis and /etc/managed-portage for you.

You're still talking about /etc, which is still unaffected by PMS. If Paludis
doesn't support a feature in /etc that you want to use, then feel free to
file a bug. If Portage supports that feature in /etc, there's no reason why
it needs to stop doing so, regardless of what it does or doesn't accept in
the tree.

David Leverton · External Since: Apr 01, 2009 Posts: 6

On Sunday 23 August 2009 02:10:36 Chip Parker wrote:
> They're the same thing. It doesn't matter if the profiles directory is
> in located in /tmp or in /usr/local/portage, the behavior of paludis
> *still* doesn't support the feature that these profiles depend on and
> portage still *HAS* since before PMS was submitted to this list as an
> RFC in August of 2006.

The behaviour of Paludis doesn't matter as far as your own /etc goes, because
you (presumably) don't use Paludis. You're free to use whatever's supported
by your own favourite package manager.

> Additionally, there isn't a way to define in paludis where the profiles
> actually exist outside of the repository configuration files, which means
> that in your mind, they're one and the same.

You can read minds now? The actual reason why the profile is configured in
the repository configuration file is that the profile used by a particular
repository's packages is a parameter to that repository. Not that that's
relevant to what you do in your own /etc, as I said above.

Chip Parker · External Since: Aug 10, 2009 Posts: 7

On Sat, Aug 22, 2009 at 5:32 PM, David Leverton<levertond.RemoveThis@googlemail.com> wrote:
> On Sunday 23 August 2009 01:26:24 Chip Parker wrote:
>> So, Ciaran, if your personal reference implementation of PMS fails
>> miserably when using this methodology, your argument that I won't be
>> or "am not" affected by your attempt at changing portage is invalid.
>> If you'd like to test for yourself, I'll be more than happy to tar up
>> both my /etc/paludis and /etc/managed-portage for you.
>
> You're still talking about /etc, which is still unaffected by PMS. Â If Paludis
> doesn't support a feature in /etc that you want to use, then feel free to
> file a bug. Â If Portage supports that feature in /etc, there's no reason why
> it needs to stop doing so, regardless of what it does or doesn't accept in
> the tree.

They're the same thing. It doesn't matter if the profiles directory is
in located in /tmp or in /usr/local/portage, the behavior of paludis
*still* doesn't support the feature that these profiles depend on and
portage still *HAS* since before PMS was submitted to this list as an
RFC in August of 2006. The argument here is that PMS should be changed
to reflect what has been being used "in the wild" since before it came
into existence, especially considering the removal of the particular
feature that this "trick" depends on would break user expected
behavior.

On Sat, Aug 22, 2009 at 5:34 PM, Ciaran
McCreesh<ciaran.mccreesh.RemoveThis@googlemail.com> wrote:
> On Sat, 22 Aug 2009 17:26:24 -0700
> Chip Parker <infowolfe.RemoveThis@gmail.com> wrote:
>> Since you have a habit of ignoring relevant bits of technical
>> opposition to some of your more insane schemes, I'll cite *again* the
>> relevant portion.
>
> I showed you the relevant portion. /etc/make.profile means it is user
> configuration, which in turn means PMS has absolutely nothing to say
> about it. Anything done under /etc/make.profile is entirely up to the
> package manager and is not covered by the specification.
>
> So for the fourth time, no-one has asked for anything that will break
> what you're doing.

You claim that PMS doesn't matter outside of a repository, and yet it
most certainly does, because as I said to David, it doesn't matter
/where/ the profiles are actually located: /etc/, /tmp/,
/usr/local/portage/, or /usr/portage/ the behavior *should* be both
consistent and not unnecessarily restricted by a specification
controlled by a person who is on the outside of the Gentoo
organization. If you'd prefer, I can merge my /etc/managed-portage
stuff with my internal overlay and then bitch loudly about you
attempting to remove features that existed prior to your involvement
in Gentoo's package managers. Additionally, there isn't a way to
define in paludis where the profiles actually exist outside of the
repository configuration files, which means that in your mind, they're
one and the same.

What you proposed in the bug you filed would specifically break how I
do things, without replacing it with an equal or better solution. Your
inability or unwillingness to comprehend that simple fact is really
not my concern.

When the most prolific committer to PMS also happens to the most
prolific committer and is listed as "owning" the repository for a
competing package manager, it looks suspiciously like conflict of
interest.

David Leverton · External Since: Apr 01, 2009 Posts: 6

On Sunday 23 August 2009 03:39:52 Arfrever Frehtes Taifersar Arahesis wrote:
> /etc/make.profile is by default a symlink to appropriate profile directory
> in ${PORTDIR}/profiles.

Again, a detail of how Portage is configured. PMS only covers profiles that
are in repositories - it's up to the package manager how to deal with ones
that are elsewhere.

Paul de Vrieze · External Since: Oct 04, 2006 Posts: 15

On Saturday 22 August 2009, Chip Parker wrote:
> 2009/8/21 Robert Buchholz <rbu.TakeThisOut@gentoo.org>:
> > On Saturday 22 August 2009, Maciej Mrozowski wrote:
> >> It's true, but being able to modularize profile may outweights the
> >> need to be strict-with-the-book here - it's a matter of usefulness. I
> >> think it should be decided by those who actually do the work in
> >> profile, whether it's worthy to push this now instead of waiting for
> >> EAPI approval.
> >>
> >> So, can profile developers share their view?
> >
> > We have kept SLOT dependencies and other >EAPI-0 features out of the
> > tree profiles, introduced profile EAPI versioning to foster
> > interoperability. Now what you propose is to break this deliberate
> > upgrade process to introduce a feature no one proposed for the profiles
> > directory in the last years?
> >
> > I wonder what the value of the PMS specification is if every time an
> > inconsistency comes up the argument is raised that it should document
> > portage behavior. EAPI 1, 2 and 3 have been agreed by the council and
> > PMS is in a stage where Portage should obey its definitions and not the
> > other way around.
> > I am not saying that this is the *fastest* way to innovate (although in
> > my opinion it is a good way to keep interoperability).
> > However this PMS process is what council has chosen for Gentoo, and
> > either you follow it, or you try to improve it (working with the PMS
> > subproject people), or you bring up a proposal to redefine how we
> > handle standards within the tree.
> >
> > Trying to ignore the fact this standard exists is a way to breakage.
> >
> >
> > Robert
>
> When the PMS "subproject" is overwhelmingly ruled by a single person
> who doesn't have official Gentoo developer status and yet it is
> allowed to remove features from portage (the reference implementation)
> that predated PMS at the direction of this same non-dev, you start to
> have a very big problem.
>
> If you were building a house, and the blueprints had been signed off
> on calling for 1 meter high doors, but the builder had built in 2
> meter high doors, would you then go back to the builder and require
> him to do something that makes those doors unusable for the vast
> majority of people entering the house?
>
> If this feature, which HAD been documented (in bugzilla and
> commitlogs) prior to the first RFC for PMS, had instead been added
> yesterday, I would completely agree that we should revert it and it
> should be part of a future specification. Since this is instead a
> situation where the blueprints were wrong and the builder was correct,
> let's not go throwing away our "normal sized" doors.
>
> Since I, as well as the only person who's loudly having an issue with
> portage and PMS not matching up in this respect, are both USERS and
> NOT Gentoo developers, it's my opinion that portage should be left
> alone and PMS should be corrected to align with the spirit, if not the
> letter of what was documented WELL after the initial commit that added
> the feature. And, since I and the main contributor to PMS are both
> users, it's also my opinion that NEITHER of us should have anything to
> do with the policy/specification defining package manager behavior for
> the most prolific package manager in use today.

Could all of you just let this go. In this case Ciaran is actually right.
Furthermore, From the beginning of the project there has been behaviour which
was technically allowed but not condoned for official packages. The more
formalized approach with EAPI/PMS is no different. Now this thread is too long
already, just shut up about it. If you find the portage behaviour desirable
and want it allowed in the tree. Well, EAPI is the way to go. Remember EAPI is
not established by Ciaran, but by the council.

Paul

--
Paul de Vrieze
Email: pauldv.TakeThisOut@gentoo.org