Mailing List Archive

On Fri, Aug 21, 2009 at 5:34 PM, Ciaran
McCreesh<ciaran.mccreesh@googlemail.com> wrote:
> On Fri, 21 Aug 2009 17:29:12 -0700
> Chip Parker <infowolfe@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.

On Sat, 22 Aug 2009 14:47:44 -0700
Chip Parker <infowolfe@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

On Sat, Aug 22, 2009 at 2:52 PM, Ciaran
McCreesh<ciaran.mccreesh@googlemail.com> wrote:
> On Sat, 22 Aug 2009 14:47:44 -0700
> Chip Parker <infowolfe@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.

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.

On Sat, 22 Aug 2009 17:26:24 -0700
Chip Parker <infowolfe@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.

--
Ciaran McCreesh

On Sat, Aug 22, 2009 at 5:32 PM, David Leverton<levertond@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@googlemail.com> wrote:
> On Sat, 22 Aug 2009 17:26:24 -0700
> Chip Parker <infowolfe@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.

On Sat, 22 Aug 2009 18:10:36 -0700
Chip Parker <infowolfe@gmail.com> wrote:
> What you proposed in the bug you filed would specifically break how I
> do things, without replacing it with an equal or better solution.

No it wouldn't. It would have no effect whatsoever on how you do things.

--
Ciaran McCreesh

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.

2009-08-23 02:34:08 Ciaran McCreesh napisał(a):
> On Sat, 22 Aug 2009 17:26:24 -0700
> Chip Parker <infowolfe@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.

/etc/make.profile is by default a symlink to appropriate profile directory
in ${PORTDIR}/profiles. Documentation of /etc/make.profile concerns also
all profile directories.

--
Arfrever Frehtes Taifersar Arahesis

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.

On Saturday 22 August 2009, Chip Parker wrote:
> 2009/8/21 Robert Buchholz <rbu@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@gentoo.org

On Sat, 22 Aug 2009 01:32:33 -0400
Andrew D Kirch <trelane@trelane.net> wrote:

> Ryan Hill wrote:
> > On Fri, 21 Aug 2009 17:29:12 -0700
> > Chip Parker <infowolfe@gmail.com> wrote:
> >
> >
> >> 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?
> >>
> >
> > Package managers can implement whatever extra bells and whistles they like,
> > but they still have to follow the spec. Your metaphor is flawed in that
> > you're talking about a single house here. If it doesn't match the plan you
> > do an as-built and file a deviation with the registrar. The situation here
> > is more like if you build a hundred houses to code, and then one above code,
> > and then change code to match the one house and bulldoze the rest for not
> > meeting minimal requirements. You're punishing anyone who implements a
> > package manager to spec if you keep changing the spec in incompatible ways.
> >
> Right, this is called "punishing innovation". It's a hobby of
> bureaucrats everywhere.
> It could also be said to be "punishing excellence". We've had a lot of
> political systems
> which try to implement a design which weeds out both the mediocre, and
> the excellent,
> leaving us with the average all have been failures. The reason why
> they fail is that it is
> the above average who do the heaviest lifting.

No, you're still missing the point. Innovation is good. Rewarding
innovation is good, which is why we change the spec in backwards-compatible
ways to incorporate the best ideas every so often, through new EAPIs. What
is bad is when one particular package manager innovates and we retroactively
change the spec to match what it does, leaving all the PM's that operate
according to what the spec previously said to do up the river.

For the record, I use portage. I have always used portage. I just don't see
the point of having a specification on how to write a PM that works with
Gentoo if we keep changing that spec on whim.



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

On Sat, 22 Aug 2009 22:22:54 +0200
Arfrever Frehtes Taifersar Arahesis <Arfrever@gentoo.org> wrote:

> 2009-08-22 21:39:47 Ciaran McCreesh napisał(a):
> > On Sat, 22 Aug 2009 01:54:22 +0100
> > AllenJB <gentoo-lists@allenjb.me.uk> wrote:
> > > Could there be room for "fast track" EAPI's to be considered on some
> > > occasions - eg. in this case an EAPI-2.1 which is simply EAPI-2 with
> > > the "package.* as directory in profiles" feature included?
> >
> > It's a possibility, since it's zero cost for Portage and an easy one
> > to word into the specification.
> >
> > Another possibly nicer option would be to add the feature into EAPI 3.
> > However, if we're considering this, we'd have to be absolutely totally
> > clear that this isn't a call to open up EAPI 3 for yet more changes.
>
> EAPI=3 can be opened also for other changes trivial to implement (e.g. allowing
> bash-4.0 features).
>

That's exactly the 'yet more changes' we're trying to avoid.


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

Hi,

Andrew D Kirch <trelane@trelane.net>:

> Ryan Hill wrote:
> > On Fri, 21 Aug 2009 17:29:12 -0700
> > Chip Parker <infowolfe@gmail.com> wrote:
> >
> >
> >> 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?
> >>
> >
> > Package managers can implement whatever extra bells and whistles
> > they like, but they still have to follow the spec. Your metaphor
> > is flawed in that you're talking about a single house here. If it
> > doesn't match the plan you do an as-built and file a deviation with
> > the registrar. The situation here is more like if you build a
> > hundred houses to code, and then one above code, and then change
> > code to match the one house and bulldoze the rest for not meeting
> > minimal requirements. You're punishing anyone who implements a
> > package manager to spec if you keep changing the spec in
> > incompatible ways.
> Right, this is called "punishing innovation". It's a hobby of
> bureaucrats everywhere.
> It could also be said to be "punishing excellence". We've had a lot
> of political systems
> which try to implement a design which weeds out both the mediocre, and
> the excellent,
> leaving us with the average all have been failures. The reason why
> they fail is that it is
> the above average who do the heaviest lifting.

The ebuild format has seen no progress in a long time, because an
intrusive change needed an update to the tree and the package manager
at the same moment and a push to users. This was near to impossible
for most interesting features. The EAPI process may be a bit
bureaucratic (it is open to anyone interested), but it ensures progress
at all. How long did people want USE dependencies? That's bug 2272
from April 2002! It has been closed in June last year.

V-Li

(Portage user and having had clashes with Ciaran, but where he is
correct one has to admit it)

--
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://gentoo.faulhammer.org/>