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

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

[Jeremy Olexa]

I am suggesting that the new 10.0 profiles be marked as EAPI-2
compliant. This involves setting the content of the 'eapi' file to "2"
and bumping up the required portage version.

This seems like progress to me. Often, developers are complaining that
they can't use SLOT syntax in profiles (I know that is EAPI-1). Since,
the only time we can bump EAPI syntax in profiles is upon a new
directory creation, this seems like a good time to me. The new
profiles are still in flux until the official stages/cd's are
produced.

Also, another good reason is: "why not?" I don't think any Gentoo user
can avoid EAPI-2 up til now anyway.

Any comments? No comments means it will be decided off-list.
Timeframe: 1 week from now.
-Jeremy

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

[Ben de Groot]

Jeremy Olexa wrote:
> I am suggesting that the new 10.0 profiles be marked as EAPI-2
> compliant. This involves setting the content of the 'eapi' file to "2"
> and bumping up the required portage version.

YES!! Please.

Ben

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

[Samuli Suominen]

Jeremy Olexa wrote:
> I am suggesting that the new 10.0 profiles be marked as EAPI-2
> compliant. This involves setting the content of the 'eapi' file to "2"
> and bumping up the required portage version.

+1

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

[Tomáš Chvátal]

[-- Attachment #1: Type: Text/Plain, Size: 1019 bytes --]

Dne středa 12 Srpen 2009 19:58:05 Jeremy Olexa napsal(a):
> I am suggesting that the new 10.0 profiles be marked as EAPI-2
> compliant. This involves setting the content of the 'eapi' file to "2"
> and bumping up the required portage version.
>
> This seems like progress to me. Often, developers are complaining that
> they can't use SLOT syntax in profiles (I know that is EAPI-1). Since,
> the only time we can bump EAPI syntax in profiles is upon a new
> directory creation, this seems like a good time to me. The new
> profiles are still in flux until the official stages/cd's are
> produced.
>
> Also, another good reason is: "why not?" I don't think any Gentoo user
> can avoid EAPI-2 up til now anyway.
>
> Any comments? No comments means it will be decided off-list.
> Timeframe: 1 week from now.
> -Jeremy
Agreed. This is great idea.
Also we should allow the stuff as directory thingus (portage already handles 
it right).
package.mask/koffice-2
package.mask/live-gnome
....

Tomas

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 310 bytes --]

On Wed, 12 Aug 2009 20:41:30 +0200
Tomáš Chvátal <scarabeus@gentoo.org> wrote:
> Also we should allow the stuff as directory thingus (portage already
> handles it right).

That's a seperate thing that needs EAPI control. You'll need to propose
it for EAPI 4 if you want that.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Arfrever Frehtes Taifersar Arahesis]

[-- Attachment #1: Type: Text/Plain, Size: 1160 bytes --]

2009-08-12 20:41:30 Tomáš Chvátal napisał(a):
> Dne středa 12 Srpen 2009 19:58:05 Jeremy Olexa napsal(a):
> > I am suggesting that the new 10.0 profiles be marked as EAPI-2
> > compliant. This involves setting the content of the 'eapi' file to "2"
> > and bumping up the required portage version.
> >
> > This seems like progress to me. Often, developers are complaining that
> > they can't use SLOT syntax in profiles (I know that is EAPI-1). Since,
> > the only time we can bump EAPI syntax in profiles is upon a new
> > directory creation, this seems like a good time to me. The new
> > profiles are still in flux until the official stages/cd's are
> > produced.
> >
> > Also, another good reason is: "why not?" I don't think any Gentoo user
> > can avoid EAPI-2 up til now anyway.
> >
> > Any comments? No comments means it will be decided off-list.
> > Timeframe: 1 week from now.
> > -Jeremy
> Agreed. This is great idea.
> Also we should allow the stuff as directory thingus (portage already handles 
> it right).
> package.mask/koffice-2
> package.mask/live-gnome
> ....

+1.

-- 
Arfrever Frehtes Taifersar Arahesis

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1027 bytes --]

On Wed, 12 Aug 2009 19:46:56 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Wed, 12 Aug 2009 20:41:30 +0200
> Tomáš Chvátal <scarabeus@gentoo.org> wrote:
> > Also we should allow the stuff as directory thingus (portage already
> > handles it right).
> 
> That's a seperate thing that needs EAPI control. You'll need to propose
> it for EAPI 4 if you want that.

Why is that (seriously curious, not disagreeing)?  Portage has supported this
for quite a while now.  Does the current PMS disallow it?

What I've really wanted for a long time is different package.mask files for
different types of masks.  eg.

package.mask/broken.mask (qa.mask?)
package.mask/removal.mask
package.mask/security.mask
package.mask/testing.mask
etc.

If this requires a EAPI change, let me be the first to request it for EAPI
4. ;)

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Tiziano Müller]

[-- Attachment #1.1: Type: text/plain, Size: 1299 bytes --]

Am Mittwoch, den 12.08.2009, 23:55 -0600 schrieb Ryan Hill:
> On Wed, 12 Aug 2009 19:46:56 +0100
> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> 
> > On Wed, 12 Aug 2009 20:41:30 +0200
> > Tomáš Chvátal <scarabeus@gentoo.org> wrote:
> > > Also we should allow the stuff as directory thingus (portage already
> > > handles it right).
> > 
> > That's a seperate thing that needs EAPI control. You'll need to propose
> > it for EAPI 4 if you want that.
> 
> Why is that (seriously curious, not disagreeing)?  Portage has supported this
> for quite a while now.  Does the current PMS disallow it?
> 
> What I've really wanted for a long time is different package.mask files for
> different types of masks.  eg.
> 
> package.mask/broken.mask (qa.mask?)
> package.mask/removal.mask
> package.mask/security.mask
> package.mask/testing.mask

To avoid collision with the current package.mask I'd prefer
package.mask.d/ for the directory. Also makes the transition easy since
we can generate package.mask out of the files in package.mask.d/.

-- 
Tiziano Müller
Gentoo Linux Developer
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-zero@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30

[-- Attachment #1.2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3551 bytes --]

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 765 bytes --]

On Wed, 12 Aug 2009 23:55:22 -0600
Ryan Hill <dirtyepic@gentoo.org> wrote:
> > That's a seperate thing that needs EAPI control. You'll need to
> > propose it for EAPI 4 if you want that.
> 
> Why is that (seriously curious, not disagreeing)?  Portage has
> supported this for quite a while now.  Does the current PMS disallow
> it?

Yup. We based the PMS wording upon the Portage documentation and the
commit message that introduced the feature, both of which explicitly
say it's only for /etc/portage/ use, not tree use. Portage's support
for directories like that in the tree is an undocumented fluke caused
by using the same code for user and tree configuration parsing without
adding extra strictness checks for the tree.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Mark Bateman]

Ciaran McCreesh <ciaran.mccreesh <at> googlemail.com> writes:

> 
> On Wed, 12 Aug 2009 20:41:30 +0200
> Tomáš Chvátal <scarabeus <at> gentoo.org> wrote:
> > Also we should allow the stuff as directory thingus (portage already
> > handles it right).
> 
> That's a seperate thing that needs EAPI control. You'll need to propose
> it for EAPI 4 if you want that.
> 

Except this "stuff as directory" was pre-EAPI and thus the PMS should have
captured that as EAPI-1
Ergo PMS is wrong and needs to be updated to refect reality

but back on topic
++ 

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 918 bytes --]

On Thu, 13 Aug 2009 12:50:26 +0000 (UTC)
Mark Bateman <couldbe@soon.com> wrote:
> > On Wed, 12 Aug 2009 20:41:30 +0200
> > Tomáš Chvátal <scarabeus <at> gentoo.org> wrote:
> > > Also we should allow the stuff as directory thingus (portage
> > > already handles it right).
> > 
> > That's a seperate thing that needs EAPI control. You'll need to
> > propose it for EAPI 4 if you want that.
> 
> Except this "stuff as directory" was pre-EAPI and thus the PMS should
> have captured that as EAPI-1
> Ergo PMS is wrong and needs to be updated to refect reality

PMS accurately reflects the Portage documentation and the commit
message that introduced the feature -- it's purely for use
in /etc/portage/, which is beyond the scope of PMS.

It is not the business of PMS to enforce undocumented features that
Portage supports only by accident and that aren't used in the tree.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Nirbheek Chauhan]

On Thu, Aug 13, 2009 at 4:05 PM, Tiziano Müller<dev-zero@gentoo.org> wrote:
> To avoid collision with the current package.mask I'd prefer
> package.mask.d/ for the directory. Also makes the transition easy since
> we can generate package.mask out of the files in package.mask.d/.
>

I completely agree with this. A script similar to metadata.xml ->
use.local.desc can be run on it (with more frequency), and eventually
(EAPI=4?) we can move away from the file-based one.

-- 
~Nirbheek Chauhan

GNOME Team, Gentoo

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

[Maciej Mrozowski]

[-- Attachment #1: Type: Text/Plain, Size: 1804 bytes --]

On Thursday 13 of August 2009 12:35:43 Tiziano Müller wrote:
> Am Mittwoch, den 12.08.2009, 23:55 -0600 schrieb Ryan Hill:
> > On Wed, 12 Aug 2009 19:46:56 +0100
> >
> > Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > > On Wed, 12 Aug 2009 20:41:30 +0200
> > >
> > > Tomáš Chvátal <scarabeus@gentoo.org> wrote:
> > > > Also we should allow the stuff as directory thingus (portage already
> > > > handles it right).
> > >
> > > That's a seperate thing that needs EAPI control. You'll need to propose
> > > it for EAPI 4 if you want that.
> >
> > Why is that (seriously curious, not disagreeing)?  Portage has supported
> > this for quite a while now.  Does the current PMS disallow it?
> >
> > What I've really wanted for a long time is different package.mask files
> > for different types of masks.  eg.
> >
> > package.mask/broken.mask (qa.mask?)
> > package.mask/removal.mask
> > package.mask/security.mask
> > package.mask/testing.mask
> 
> To avoid collision with the current package.mask I'd prefer
> package.mask.d/ for the directory. Also makes the transition easy since
> we can generate package.mask out of the files in package.mask.d/.

package.mask.d being directory and not used internally by PM - so being just a 
convention (which may be used for manually or scripted generation of resulting 
package.mask as dev-zero proposed- it's now utilized in kde-testing overlay 
because package.mask dir used to cause paludis crashes) can be implemented 
just now with no PMS changes (since PM is supposed to ignore unknown 
files/directories in there?).

I'd suggest allowing package.mask as either directory or file though, no need 
for entities multiplying... besides the reference implementation in already 
there for ages.

-- 
regards
MM

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Mark Bateman]

Ciaran McCreesh <ciaran.mccreesh <at> googlemail.com> writes:

> 
> On Thu, 13 Aug 2009 12:50:26 +0000 (UTC)
> Mark Bateman <couldbe <at> soon.com> wrote:
> > > On Wed, 12 Aug 2009 20:41:30 +0200
> > > Tomáš Chvátal <scarabeus <at> gentoo.org> wrote:
> > > > Also we should allow the stuff as directory thingus (portage
> > > > already handles it right).
> > > 
> > > That's a seperate thing that needs EAPI control. You'll need to
> > > propose it for EAPI 4 if you want that.
> > 
> > Except this "stuff as directory" was pre-EAPI and thus the PMS should
> > have captured that as EAPI-1
> > Ergo PMS is wrong and needs to be updated to refect reality
> 
> PMS accurately reflects the Portage documentation and the commit
> message that introduced the feature -- it's purely for use
> in /etc/portage/, which is beyond the scope of PMS.
> 
> It is not the business of PMS to enforce undocumented features that
> Portage supports only by accident and that aren't used in the tree.
> 

PMS doesn't depict just what portage should do, just what ebuild's in the main
tree are to expect.
This is a good feature (intentional or not) of portage and is already finding
usage in overlays.

Sure for such a feature to make it into the main tree EAPI it, but as it stands
its fine

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 959 bytes --]

On Thu, 13 Aug 2009 17:32:56 +0000 (UTC)
Mark Bateman <couldbe@soon.com> wrote:
> > It is not the business of PMS to enforce undocumented features that
> > Portage supports only by accident and that aren't used in the tree.
> 
> PMS doesn't depict just what portage should do, just what ebuild's in
> the main tree are to expect.

PMS documents what ebuilds may or may not rely upon from the package
manager. PMS, like the Portage document, says that package.mask is a
file.

> This is a good feature (intentional or not) of portage and is already
> finding usage in overlays.

And it shouldn't be until it's gone through the proper process to
become a documented, controlled feature rather than an accident people
are exploiting.

Seriously, this isn't difficult to do. I get the impression people are
only trying to avoid doing it properly here so they can establish a
precedent of not doing things properly...

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Mark Bateman]

Ciaran McCreesh <ciaran.mccreesh <at> googlemail.com> writes:
> PMS documents what ebuilds may or may not rely upon from the package
> manager. PMS, like the Portage document, says that package.mask is a
> file.

And main tree ebuild can rely on that. There are no directory-based 
package.mask in the main portage tree


> And it shouldn't be until it's gone through the proper process to
> become a documented, controlled feature rather than an accident people
> are exploiting.
> 
> Seriously, this isn't difficult to do. I get the impression people are
> only trying to avoid doing it properly here so they can establish a
> precedent of not doing things properly...
> 

And if a developer would like to have it present in the main tree, sure push 
for an EAPI for it to be available in the main tree. But as a feature that 
portage has that overlays can use it is useful.
Ebuilds in the main tree can still exist safe in the knowledge they won't 
have this

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1218 bytes --]

On Thu, 13 Aug 2009 18:06:04 +0000 (UTC)
Mark Bateman <couldbe@soon.com> wrote:
> > And it shouldn't be until it's gone through the proper process to
> > become a documented, controlled feature rather than an accident
> > people are exploiting.
> > 
> > Seriously, this isn't difficult to do. I get the impression people
> > are only trying to avoid doing it properly here so they can
> > establish a precedent of not doing things properly...
> 
> And if a developer would like to have it present in the main tree,
> sure push for an EAPI for it to be available in the main tree.

Uh, yes, and that's what was being discussed before you jumped in and
claimed that PMS should support it already.

> But as a feature that portage has that overlays can use it is useful.

Not if those overlays want to claim any degree of PMS compliance. I'll
remind you that not following PMS and instead relying upon flukes in
Portage behaviour means your overlay can stop working at any moment and
with no warning. It also means your overlay will only be usable with
Portage, which won't sit very well with users of the dozen or more
other tools that work with ebuilds and repositories.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Steven J Long]

Ciaran McCreesh wrote:

> On Thu, 13 Aug 2009 12:50:26 +0000 (UTC)
> Mark Bateman <couldbe@soon.com> wrote:
>> > On Wed, 12 Aug 2009 20:41:30 +0200
>> > Tomáš Chvátal <scarabeus <at> gentoo.org> wrote:
>> > > Also we should allow the stuff as directory thingus (portage
>> > > already handles it right).
>> > 
>> > That's a seperate thing that needs EAPI control. You'll need to
>> > propose it for EAPI 4 if you want that.
>> 
>> Except this "stuff as directory" was pre-EAPI and thus the PMS should
>> have captured that as EAPI-1
>> Ergo PMS is wrong and needs to be updated to refect reality
> 
> PMS accurately reflects the Portage documentation and the commit
> message that introduced the feature -- it's purely for use
> in /etc/portage/, which is beyond the scope of PMS.
>
If it's pre-EAPI it's part of EAPI '0'. That you neglected to document it,
for whatever reason, is irrelevant.
 
> It is not the business of PMS to enforce undocumented features
It's not undocumented, as you just pointed out above.

> that Portage supports only by accident
Oh, so now you know the minds of the portage developers?

I'd like to present an alternative viewpoint: portage developers are happy
to work to PMS, since it has utility for users. But ultimately, they're not
that bothered about pushing for new things, since the process means dealing
with you; adding features for portage only and leaving it up to the wider
community to push for them in EAPIs is an awful lot less hassle.

> and that aren't used in the tree. 
>
Circular argument, don't you think? It's not in-tree so we won't put it in
PMS. It's not in PMS, so it's not allowed in-tree.

And don't forget, we have to "claim PMS compliance" to which you are the
gatekeeper.
 
I'd like to ask the Council to consider whether EAPI development has not in
fact supplanted a large part of the GLEP process (specifically the
technical aspects to do with ebuild development.) As such, insisting on all
discussion on bugzilla is in fact a subversion of the original process that
people have agreed upon.

-- 
#friendly-coders -- We're friendly but we're not /that/ friendly ;-)

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 2616 bytes --]

On Thu, 13 Aug 2009 19:22:16 +0100
Steven J Long <slong@rathaus.eclipse.co.uk> wrote:
> > PMS accurately reflects the Portage documentation and the commit
> > message that introduced the feature -- it's purely for use
> > in /etc/portage/, which is beyond the scope of PMS.
> >
> If it's pre-EAPI it's part of EAPI '0'. That you neglected to
> document it, for whatever reason, is irrelevant.

No, it's not part of EAPI 0. It's an accident. If you'd like another
example of an accident, Portage won't complain if you stick garbage in
certain metadata keys; this does not mean PMS should say that it's
legal to put garbage in metadata keys.

> > It is not the business of PMS to enforce undocumented features
> It's not undocumented, as you just pointed out above.

Using it in the tree is undocumented. Using it in user configuration is
beyond the scope of PMS.

> > that Portage supports only by accident
> Oh, so now you know the minds of the portage developers?

Yes. I know that they said when adding the directory feature that it
was for use in user configuration files. That's what the commit message
said, and that's what the documentation patch said. The documentation
change explicitly only allowed the feature in user configuration, not
the tree.

Had the feature intended to be tree-usable, the documentation change
would have said so.

> I'd like to present an alternative viewpoint: portage developers are
> happy to work to PMS, since it has utility for users. But ultimately,
> they're not that bothered about pushing for new things, since the
> process means dealing with you; adding features for portage only and
> leaving it up to the wider community to push for them in EAPIs is an
> awful lot less hassle.

Even a casual look at EAPI 3 will show that that is nonsense. But then,
you already know that from the previous times that claim has been made
and refuted.

> > and that aren't used in the tree. 
>
> Circular argument, don't you think? It's not in-tree so we won't put
> it in PMS. It's not in PMS, so it's not allowed in-tree.

That's only a circular argument if you snip out the rest of the
sentence.

> I'd like to ask the Council to consider whether EAPI development has
> not in fact supplanted a large part of the GLEP process (specifically
> the technical aspects to do with ebuild development.) As such,
> insisting on all discussion on bugzilla is in fact a subversion of
> the original process that people have agreed upon.

Moving the discussion to bugzilla was the Council's decision, not mine.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1057 bytes --]

On Thu, 13 Aug 2009 13:29:04 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Wed, 12 Aug 2009 23:55:22 -0600
> Ryan Hill <dirtyepic@gentoo.org> wrote:
> > > That's a seperate thing that needs EAPI control. You'll need to
> > > propose it for EAPI 4 if you want that.
> > 
> > Why is that (seriously curious, not disagreeing)?  Portage has
> > supported this for quite a while now.  Does the current PMS disallow
> > it?
> 
> Yup. We based the PMS wording upon the Portage documentation and the
> commit message that introduced the feature, both of which explicitly
> say it's only for /etc/portage/ use, not tree use. Portage's support
> for directories like that in the tree is an undocumented fluke caused
> by using the same code for user and tree configuration parsing without
> adding extra strictness checks for the tree.

Alright, thanks.


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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Steven J Long]

Ciaran McCreesh wrote:

> On Thu, 13 Aug 2009 19:22:16 +0100
> Steven J Long <slong@rathaus.eclipse.co.uk> wrote:
>> > PMS accurately reflects the Portage documentation and the commit
>> > message that introduced the feature -- it's purely for use
>> > in /etc/portage/, which is beyond the scope of PMS.
>> >
>> If it's pre-EAPI it's part of EAPI '0'. That you neglected to
>> document it, for whatever reason, is irrelevant.
> 
> No, it's not part of EAPI 0.
If it's a feature that is pre-PMS, it's part of EAPI-0. The definition is
flexible, presumably to avoid this kind of runaround.

> It's an accident. If you'd like another 
> example of an accident, Portage won't complain if you stick garbage in
> certain metadata keys; this does not mean PMS should say that it's
> legal to put garbage in metadata keys.
>
That's irrelevant and you know it, apart from being one of your usual
political digs at portage.
 
>> > It is not the business of PMS to enforce undocumented features
>> It's not undocumented, as you just pointed out above.
> 
> Using it in the tree is undocumented.
But it's not an "undocumented feature" is it?

> Using it in user configuration is beyond the scope of PMS.
Define 'user'

>> > that Portage supports only by accident
>> Oh, so now you know the minds of the portage developers?
> 
> Yes.
No, you clearly do not, as this shows:

> I know that they said when adding the directory feature that it 
> was for use in user configuration files. That's what the commit message
> said, and that's what the documentation patch said. The documentation
> change explicitly only allowed the feature in user configuration, not
> the tree.
> 
> Had the feature intended to be tree-usable, the documentation change
> would have said so.
>
Thanks for explaining what "the Portage documentation and the commit
message" means. And yeah, you can read it. Well done. It *does not* mean you
know what future directions might have been envisaged.

<snip> 
>> > and that aren't used in the tree.
>>
>> Circular argument, don't you think? It's not in-tree so we won't put
>> it in PMS. It's not in PMS, so it's not allowed in-tree.
> 
> That's only a circular argument if you snip out the rest of the
> sentence.
>
Nonsense. You gave the fact that it's not used in the tree as a reason not
to put it in PMS, did you not? I merely addressed it separately, since it
is a distinct semantic component.
 
>> I'd like to ask the Council to consider whether EAPI development has
>> not in fact supplanted a large part of the GLEP process (specifically
>> the technical aspects to do with ebuild development.) As such,
>> insisting on all discussion on bugzilla is in fact a subversion of
>> the original process that people have agreed upon.
> 
> Moving the discussion to bugzilla was the Council's decision, not mine.
> 
Yes, well, I didn't ask you. I asked the Council to consider the broader
picture, which is their role, since effectively GLEPs are now only for
non-technical things, or might as well be, since all future ebuild
directions are EAPI by definition. Having wider input (which is what this
list is for) might avoid future blind-alleys.

Nevertheless, I'm sure they'll take your valuable insight under
consideration, as well as the history and any lobbying that might have gone
on at the time, assuming they were around and haven't suppressed the
memory.

-- 
#friendly-coders -- We're friendly but we're not /that/ friendly ;-)

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

[Rémi Cardona]

Le 18/08/2009 03:30, Steven J Long a écrit :
[snip]

Steven,

This thread was dead for more than 4 days. Yet you pick it up and you 
try to pick a fight with Ciaran.

I for one am tired of your behavior on this list and I will not hesitate 
to contact UserRel to get you out of this list if you don't settle down 
and start acting like an adult.

Now step away from this thread.

Thanks

Rémi

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

[Steven J Long]

Rémi Cardona wrote:

> Le 18/08/2009 03:30, Steven J Long a écrit :
> [snip]
> 
> Steven,
> 
> This thread was dead for more than 4 days. Yet you pick it up and you
> try to pick a fight with Ciaran.
>
No I was answering the points he made, specifically he gave the fact that
something's not used in the tree as a reason not to put it in PMS. The
prior mail about an alternative perspective on the process was about his
continual digs at portage and its developers. You're right that much of it
was more relevant to -project, but when I post there it gets ignored:
http://archives.gentoo.org/gentoo-project/msg_6c82019575749b628de20de060149782.xml
http://archives.gentoo.org/gentoo-project/msg_28e2659029951f7edeab10b01cd21d53.xml
 
> I for one am tired of your behavior on this list
Fair enough. I'm tired of ciaran's, and I'm bemused that you didn't take the
opportunity to contact me off-list to discuss this. I'm on IRC most of the
time, as any of several Gentoo developers could have told you.

> and I will not hesitate 
> to contact UserRel to get you out of this list if you don't settle down
> and start acting like an adult.
>
If you wish to raise a bug go ahead. As for being adult-like, you don't seem
to have behaved so yourself, afaIc. No, some of us don't respond the very
next minute, nor do we consider 4 days a long time. Perhaps for a student
with far too much time on his hands, it might be.

The main point I was talking about was the subversion of the GLEP process by
the EAPI one. You might have missed it; next time try reading the whole
mail.
 
> Now step away from this thread.
> 
Done.
-- 
#friendly-coders -- We're friendly but we're not /that/ friendly ;-)

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

[Andrew D Kirch]

Steven J Long wrote:
> Rémi Cardona wrote:
>
>   
>> Le 18/08/2009 03:30, Steven J Long a écrit :
>> [snip]
>>
>> Steven,
>>
>> This thread was dead for more than 4 days. Yet you pick it up and you
>> try to pick a fight with Ciaran.
>>
>>     
> No I was answering the points he made, specifically he gave the fact that
> something's not used in the tree as a reason not to put it in PMS. The
> prior mail about an alternative perspective on the process was about his
> continual digs at portage and its developers. You're right that much of it
> was more relevant to -project, but when I post there it gets ignored:
> http://archives.gentoo.org/gentoo-project/msg_6c82019575749b628de20de060149782.xml
> http://archives.gentoo.org/gentoo-project/msg_28e2659029951f7edeab10b01cd21d53.xml
>   

I think it's clear at this point that Ciaran was the wrong person to
have in charge of the PMS or EAPI spec's despite his willingness to do
the work..  I tried to talk to him about having Paludis support an
extension of PMS which Portage already supported.  His response was to
DEMAND that portage change his behavior and throw warnings about this
because it wasn't in the PMS (which I will note is an accurately
acronym'd document).

ttp://bugs.gentoo.org/show_bug.cgi?id=273261

The users simply don't care about this stuff, and throwing warnings at
every user in the manner advocated is abuse.

This sort of behavior simply needs to stop.  Using bugs.gentoo.org to
attack Funtoo, which utilizes Portage, in the manner which has been done
usurps the Gentoo Council's authority, the Portage devs, Funtoo, and
most importantly our ability to innovate.
And hell, if we're not going to innovate, lets all please pack up and go
home.

Andrew D Kirch
Funtoo





Andrew D Kirch
Funtoo.org

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1695 bytes --]

On Thu, 20 Aug 2009 06:13:59 -0400
Andrew D Kirch <trelane@trelane.net> wrote:
> I think it's clear at this point that Ciaran was the wrong person to
> have in charge of the PMS or EAPI spec's despite his willingness to do
> the work..  I tried to talk to him about having Paludis support an
> extension of PMS which Portage already supported.  His response was to
> DEMAND that portage change his behavior and throw warnings about this
> because it wasn't in the PMS (which I will note is an accurately
> acronym'd document).
> 
> ttp://bugs.gentoo.org/show_bug.cgi?id=273261

...and then for the feature to be introduced properly, in a controlled
manner, yes.

> The users simply don't care about this stuff, and throwing warnings at
> every user in the manner advocated is abuse.

The warnings don't make it to the user. The warnings make sure
developers catch the problem and fix it.

> This sort of behavior simply needs to stop.  Using bugs.gentoo.org to
> attack Funtoo, which utilizes Portage, in the manner which has been
> done usurps the Gentoo Council's authority, the Portage devs, Funtoo,
> and most importantly our ability to innovate.

Funtoo can do whatever it wants. There are plenty of ways for it to do
that. One way might be for Funtoo to make its own EAPI including the
extensions it needs, and get Portage to support that. Unfortunately,
your incorrect belief that EAPIs had nothing to do with Portage when
this came up prevented you from considering that solution.

> And hell, if we're not going to innovate, lets all please pack up and
> go home.

I look forward to seeing Funtoo's creation of EAPI funtoo-2.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Andrew D Kirch]

Ciaran McCreesh wrote:
> On Thu, 20 Aug 2009 06:13:59 -0400
> Andrew D Kirch <trelane@trelane.net> wrote:
>   
>
> > I look forward to seeing Funtoo's creation of EAPI funtoo-2.
>   

Obviously you don't get it.  We aren't going to spend time writing this
sort of spurious and unnecessary specification documents.  The fact that
this is even conscionable would be hugely concerning except for the fact
that you are not a Gentoo dev.  Nor do you, as I have proven, have
standing to file such a bug as you are not on the council (even as an
alternate), and the SOLE option for packages violating PMS per the
council is a council vote to mask the package. 

I'm having a hard time reconciling the following:

"The warnings don't make it to the user. The warnings make sure
developers catch the problem and fix it."

And:

"Just do it unconditionally. We're talking the tree here, not user
configuration files, so enforcing QA can only be a good thing."
"Portage should instead warn or error when this happens to prevent
people from accidentally abusing this."

Also:

"No. It's in direct violation of PMS, and only accidentally works with
Portage until Portage is fixed."

And:

"Portage should instead warn or error when this happens to prevent
people from accidentally abusing this."


Portage is a tool used by users, repoman is a tool used by developers
for tree QA.  Considering the zeal with which you are pushing this
"accidentally works with Portage until Portage is fixed", I believe a
reasonable person is going to look at the b.g.o bug, and at the Paludis
bug and realize that you're more interested in process than innovation,
and that you simply don't care about throwing needless confusing
warnings at users (indeed a prima facia examination of Paludis would
seem to confirm this, and my concerns WRT Paludis and the development
methods are well known).  I think they'll also realize that throughout
this process you've been less than honest, and a huge impairment to the
work going on at Funtoo.

Would someone who has access please resolve the bug as WONTFIX?  Thanks.

Andrew D Kirch
Funtoo.org

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 2422 bytes --]

On Thu, 20 Aug 2009 13:36:30 -0400
Andrew D Kirch <trelane@trelane.net> wrote:
> > > I look forward to seeing Funtoo's creation of EAPI funtoo-2.
> 
> Obviously you don't get it.  We aren't going to spend time writing
> this sort of spurious and unnecessary specification documents.

Why not? Are you saying you don't want the way Funtoo's package manager
works to be documented? I'll remind you that the feature in question
isn't documented anywhere.

It's a five minute job, and it will mean Funtoo's tree can be used by
any of the many third party tools that work with repositories.

I find it hard to believe that one of Funtoo's goals is to use
undocumented features and not have any way for contributors to know what
the package format is.

> Nor do you, as I have proven, have standing to file such a bug as you
> are not on the council (even as an alternate), and the SOLE option
> for packages violating PMS per the council is a council vote to mask
> the package. 

That's not the sole option at all. The first thing to do is to get the
issue fixed. Masking is the nuclear option.

> Portage is a tool used by users, repoman is a tool used by developers
> for tree QA.

repoman isn't an effective way of getting messages to overlay
developers.

>  Considering the zeal with which you are pushing this
> "accidentally works with Portage until Portage is fixed", I believe a
> reasonable person is going to look at the b.g.o bug, and at the
> Paludis bug and realize that you're more interested in process than
> innovation, and that you simply don't care about throwing needless
> confusing warnings at users (indeed a prima facia examination of
> Paludis would seem to confirm this, and my concerns WRT Paludis and
> the development methods are well known).  I think they'll also
> realize that throughout this process you've been less than honest,
> and a huge impairment to the work going on at Funtoo.

The process for innovation is EAPIs. This allows innovation to go
through in a well defined manner that doesn't cause highly random
breakage every time a new feature comes along. Unfortunately, your
early misconception that EAPIs are about Paludis is getting in the way
of you taking a few simple steps to turn this from exploiting
undocumented behaviour to a well defined feature.

EAPIs are there to help you, not hold you back.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Steven J Long]

Ciaran McCreesh wrote:

> I look forward to seeing Funtoo's creation of EAPI funtoo-2.
> 
Well judging by your EAPI-2, I'd prefer it. Apart from USE-deps, there's
been no discussion apart from under your supervision on bugzie.
nonfatal? (or w/e it's called.) Who came up with that idea, and why did you
ignore the --or-die option that's already been discussed?

If you want exceptions, try C++ (better than you're currently doing.) This
is shellscript.

I'd like to moot to the Council that we hold off on EAPI-2 profiles, and go
with EAPI-1 plus USE-deps and BASH-3.2_p17 (honestly, you thought 4 was
ready?!) til we get this mess sorted.

-- 
#friendly-coders -- We're friendly but we're not /that/ friendly ;-)

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

[Chip Parker]

On Thu, Aug 20, 2009 at 5:04 PM, Steven J
Long<slong@rathaus.eclipse.co.uk> wrote:
> Ciaran McCreesh wrote:
>
>> I look forward to seeing Funtoo's creation of EAPI funtoo-2.
>>
> Well judging by your EAPI-2, I'd prefer it. Apart from USE-deps, there's
> been no discussion apart from under your supervision on bugzie.
> nonfatal? (or w/e it's called.) Who came up with that idea, and why did you
> ignore the --or-die option that's already been discussed?
>
> If you want exceptions, try C++ (better than you're currently doing.) This
> is shellscript.
>
> I'd like to moot to the Council that we hold off on EAPI-2 profiles, and go
> with EAPI-1 plus USE-deps and BASH-3.2_p17 (honestly, you thought 4 was
> ready?!) til we get this mess sorted.
>

How about we just ignore ciaranm because he's got no valid complaints
or objections to this particular portage behavior as shown in
https://bugs.gentoo.org/show_bug.cgi?id=273261#c28.

Relevant portion excerpted here for your convenience:
"Additionally, in
http://sources.gentoo.org/viewcvs.py/portage/main/trunk/pym/portage.py?rev=3495&view=markup
(hint: look for "recursive=1") and
http://bugs.gentoo.org/show_bug.cgi?id=133740, with both predating the
initial RFC for PMS sent to gentoo-dev mailing list, this behavior is
discussed and shown to be a design feature, not a flaw or lack of QA
in portage. This proves with certainty that it is PMS and the views of
the reporter of this bug that are flawed, and not the behavior of
portage."

Problem solved.

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

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1444 bytes --]

On Thu, 20 Aug 2009 11:02:23 +0100
Steven J Long <slong@rathaus.eclipse.co.uk> wrote:

> Rémi Cardona wrote:
> 
> > Le 18/08/2009 03:30, Steven J Long a écrit :
> > [snip]
> > 
> > Steven,
> > 
> > This thread was dead for more than 4 days. Yet you pick it up and you
> > try to pick a fight with Ciaran.
> >
> No I was answering the points he made, specifically he gave the fact that
> something's not used in the tree as a reason not to put it in PMS. The
> prior mail about an alternative perspective on the process was about his
> continual digs at portage and its developers. You're right that much of it
> was more relevant to -project, but when I post there it gets ignored:
> http://archives.gentoo.org/gentoo-project/msg_6c82019575749b628de20de060149782.xml
> http://archives.gentoo.org/gentoo-project/msg_28e2659029951f7edeab10b01cd21d53.xml

Steve,

No one cares how you feel about Ciaran.  Please stop replying to threads that
have nothing to do with your personal feelings towards others for the sake of
informing us what they are.  We honestly don't care.  Get a blog.  Call it
"Ciaran's a meanie".  Invite like-minded individuals to collaborate.  Make a
damned Facebook group for all I care.  But please keep it off this list.


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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Arfrever Frehtes Taifersar Arahesis]

[-- Attachment #1: Type: Text/Plain, Size: 797 bytes --]

2009-08-13 07:55:22 Ryan Hill napisał(a):
> On Wed, 12 Aug 2009 19:46:56 +0100
> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> 
> > On Wed, 12 Aug 2009 20:41:30 +0200
> > Tomáš Chvátal <scarabeus@gentoo.org> wrote:
> > > Also we should allow the stuff as directory thingus (portage already
> > > handles it right).
> > 
> > That's a seperate thing that needs EAPI control. You'll need to propose
> > it for EAPI 4 if you want that.
> 
> Why is that (seriously curious, not disagreeing)?  Portage has supported this
> for quite a while now.  Does the current PMS disallow it?

Portage documentation has been properly fixed (and the fix will be released
in next version) and this feature can now be used in 10.0 profiles.

-- 
Arfrever Frehtes Taifersar Arahesis

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[David Leverton]

2009/8/21 Arfrever Frehtes Taifersar Arahesis <Arfrever@gentoo.org>:
> Portage documentation has been properly fixed (and the fix will be released
> in next version) and this feature can now be used in 10.0 profiles.

No.  Changing the documentation does not retroactively change existing EAPIs.

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

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1141 bytes --]

On Fri, 21 Aug 2009 16:25:35 +0200
Arfrever Frehtes Taifersar Arahesis <Arfrever@gentoo.org> wrote:

> 2009-08-13 07:55:22 Ryan Hill napisał(a):
> > On Wed, 12 Aug 2009 19:46:56 +0100
> > Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > 
> > > On Wed, 12 Aug 2009 20:41:30 +0200
> > > Tomáš Chvátal <scarabeus@gentoo.org> wrote:
> > > > Also we should allow the stuff as directory thingus (portage already
> > > > handles it right).
> > > 
> > > That's a seperate thing that needs EAPI control. You'll need to propose
> > > it for EAPI 4 if you want that.
> > 
> > Why is that (seriously curious, not disagreeing)?  Portage has supported this
> > for quite a while now.  Does the current PMS disallow it?
> 
> Portage documentation has been properly fixed (and the fix will be released
> in next version) and this feature can now be used in 10.0 profiles.

How does changing the portage documentation magically add this to the PMS?


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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Arfrever Frehtes Taifersar Arahesis]

[-- Attachment #1: Type: Text/Plain, Size: 1158 bytes --]

2009-08-21 23:17:56 Ryan Hill napisał(a):
> On Fri, 21 Aug 2009 16:25:35 +0200
> Arfrever Frehtes Taifersar Arahesis <Arfrever@gentoo.org> wrote:
> 
> > 2009-08-13 07:55:22 Ryan Hill napisał(a):
> > > On Wed, 12 Aug 2009 19:46:56 +0100
> > > Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > > 
> > > > On Wed, 12 Aug 2009 20:41:30 +0200
> > > > Tomáš Chvátal <scarabeus@gentoo.org> wrote:
> > > > > Also we should allow the stuff as directory thingus (portage already
> > > > > handles it right).
> > > > 
> > > > That's a seperate thing that needs EAPI control. You'll need to propose
> > > > it for EAPI 4 if you want that.
> > > 
> > > Why is that (seriously curious, not disagreeing)?  Portage has supported this
> > > for quite a while now.  Does the current PMS disallow it?
> > 
> > Portage documentation has been properly fixed (and the fix will be released
> > in next version) and this feature can now be used in 10.0 profiles.
> 
> How does changing the portage documentation magically add this to the PMS?

PMS developers are unwilling to fix many bugs in PMS.

-- 
Arfrever Frehtes Taifersar Arahesis

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 940 bytes --]

On Fri, 21 Aug 2009 23:42:11 +0200
Arfrever Frehtes Taifersar Arahesis <Arfrever@gentoo.org> wrote:
> > How does changing the portage documentation magically add this to
> > the PMS?
> 
> PMS developers are unwilling to fix many bugs in PMS.

This is not a bug in PMS.

PMS accurately reflected the Portage documentation at the time it was
written and at the time it was approved. In addition, there was no real
world use of this feature so there was no grounds to consider making it
part of the specification despite it being undocumented. Thus, the way
PMS was written was correct.

What you are asking for would be like retroactively updating the HTML 4
specification to mandate a particular undocumented quirk of Internet
Explorer 6's behaviour.

The correct way to proceed is to use EAPI 4 to move this to be a
specified feature, and to permit it only for profiles marked as using
EAPI 4.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Maciej Mrozowski]

[-- Attachment #1: Type: Text/Plain, Size: 897 bytes --]

On Friday 21 of August 2009 23:46:38 Ciaran McCreesh wrote:
> On Fri, 21 Aug 2009 23:42:11 +0200

> PMS accurately reflected the Portage documentation at the time it was
> written and at the time it was approved.
Agreed, but I think it was supposed to reflect Portage 'behaviour' at the 
time. Of course it's hard to blame anyone for it, especially after all these 
years.

> The correct way to proceed is to use EAPI 4 to move this to be a
> specified feature, and to permit it only for profiles marked as using
> EAPI 4.

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?

-- 
regards
MM

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Robert Buchholz]

[-- Attachment #1: Type: text/plain, Size: 1480 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Chip Parker]

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.

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 454 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[AllenJB]

Robert Buchholz wrote:
> 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

From what I've seen here, at least part of the problem here stems from
the fact that this feature won't be considered until EAPI-4, and that
means it might be a long way off yet. This, in my mind, raises the
question of whether the current PMS/EAPI process is too slow in certain
circumstances and could it be modified to speed things up when deemed
necessary?

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?

If this is a matter of what the council has decided, would a simple
solution be to have a motion for amendment / fast-track of EAPI2.1 (or
alternative solution) brought up and voted on by the council?

AllenJB

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

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1184 bytes --]

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.


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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Duncan]

Robert Buchholz posted on Sat, 22 Aug 2009 01:44:51 +0200 as excerpted:

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

> Trying to ignore the fact this standard exists is a way to breakage.

There are, as I see it, two issues here.

1) This feature can be reasonably argued to have fallen thru the cracks, 
since it was actually implemented before PMS.  Yes, the committing 
documentation said it was for user config only, but the implementation 
was in general, and in general, EAPI-0 was to document existing behavior, 
so we have a problem.  It's thus one of a very limited number of 
candidates, and it's not like there's going to be hundreds more where 
this came from.

2) If I'm not mistaken, EAPI-0 has never been fully finalized anyway.  It 
has gotten to preliminary approval, where bugs are supposed to be filed 
where there's a conflict, and a resolution worked out.  All other 
approved EAPIs have been defined as differences from previous versions, 
but due to the way EAPI-0 came about, nobody has really been sure enough 
it's 100% defined, and final approval hasn't happened as a result.  Given 
that this feature was there before PMS. despite what the documentation 
actually said, it's precisely the type of bug that was intended to be 
covered by the preliminary approval, and hammering it out as that 
preliminary approval outlined is where we're at right now.

If #2 is indeed correct, then we don't have a loophole, we have a 
legitimate bug that's we're in the process of hashing out, and it's not 
at all clear cut whether the bug is in portage and arguably the original 
documentation or in PMS.  That's a matter of viewpoint that will likely 
take a council vote to solve.

However, as I pointed out on the bug, either way it's not particularly 
difficult to solve it.  Should council decide to run with the existing 
portage behavior, since it has been there for years, the old pre-PMS wait-
a-year before changes can be allowed in tree need not apply.  I suggested 
30-90 days before it's allowed in official overlays, and 90-180 days 
before it's allowed in-tree, altho using it only in the new profiles 
works too.

If it goes the other way, then as Zac points out, it's a simple matter to 
change the portage documentation once again, and since it's not in-tree 
yet (well, at least before the new-profile announcement, and anything 
that new and limited to them can be reverted fairly easily too), not a 
big deal.  It can then wait for EAPI-4

But regardless, it /does/ appear it'll take a council vote on this, one 
way or the other.  The matter has been requested for the next council 
meeting.  I'd hope everybody can agree to just slow down a bit until 
then. (Zac just committed a portage documentation note mentioning it's 
not in PMS yet, and no intervening releases have been made with the 
questioned wording /without/ that clause, AFAIK, so that end's covered.) 
If at that point it's postponed, that too is effectively a decision, but 
I should hope it won't be postponed, as it's relatively simple either 
way, and we need a resolution from council, as the authoritative body 
designated to resolve such issues, both in general, and if I'm not 
mistaken, in the preliminary EAPI-0 approval.

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

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

[Andrew D Kirch]

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.

Andrew D Kirch
Funtoo.org

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

[Tiziano Müller]

[-- Attachment #1.1: Type: text/plain, Size: 1385 bytes --]

Am Samstag, den 22.08.2009, 01:54 +0100 schrieb AllenJB:
> From what I've seen here, at least part of the problem here stems from
> the fact that this feature won't be considered until EAPI-4, and that
> means it might be a long way off yet. This, in my mind, raises the
> question of whether the current PMS/EAPI process is too slow in certain
> circumstances and could it be modified to speed things up when deemed
> necessary?
> 
> 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?
> 
> If this is a matter of what the council has decided, would a simple
> solution be to have a motion for amendment / fast-track of EAPI2.1 (or
> alternative solution) brought up and voted on by the council?

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

-- 
Tiziano Müller
Gentoo Linux Developer
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-zero@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30

[-- Attachment #1.2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3551 bytes --]

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

[Andrew D Kirch]

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

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

[Arttu V.]

On 8/22/09, Andrew D Kirch <trelane@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 ;) ). I think that also
Microsoft calls that 'innovation'. :D

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

-- 
Arttu V.

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

[Tiziano Müller]

[-- Attachment #1.1: Type: text/plain, Size: 1442 bytes --]

Am Samstag, den 22.08.2009, 02:23 -0400 schrieb Andrew D Kirch:
> 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,
Portage just happens to be one of the package managers to implement the
specs afterwards. Since you agree with me about implementation taking
too long a pretty easy conclusion is that the portage team is already
understaffed so moving even more responsibility/work there makes the
whole process even slower. (Besides the fact of not including other
package manager devs in the process, but guessing from your earlier
comments you don't care about that.)

>  and GLEPs assigned as necessary until final
> approval or dissent is given by the council.
And you moaned about bureaucracy earlier today? Interesting.


-- 
Tiziano Müller
Gentoo Linux Developer
Areas of responsibility:
  Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor
E-Mail   : dev-zero@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5  4DE2 1B05 6A63 AE9C 1E30

[-- Attachment #1.2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3551 bytes --]

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1127 bytes --]

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.

Zac said three months ago that Portage EAPI 3 support would be done in
a month, so it can't be far off ready.

We also need to consider whether people even want it done exactly the
way Portage does it now. Some developers have expressed a preference
for a package.mask.d of some kind instead.

So yes, it's something that could be done, if the Council is interested
and if it's not going to be used as an excuse to try to shove a whole
load of other things through at the same time.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Arfrever Frehtes Taifersar Arahesis]

[-- Attachment #1: Type: Text/Plain, Size: 830 bytes --]

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

-- 
Arfrever Frehtes Taifersar Arahesis

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 617 bytes --]

On Sat, 22 Aug 2009 22:22:54 +0200
Arfrever Frehtes Taifersar Arahesis <Arfrever@gentoo.org> wrote:
> > 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 isn't a trivial implementation feature unless GLEP 55 is passed,
since it breaks sourcing for metadata for users of older Portage
versions.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 2450 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1162 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Chip Parker]

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.

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 791 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Chip Parker]

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.

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

[David Leverton]

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.

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 626 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Chip Parker]

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.

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 320 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[David Leverton]

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.

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

[Arfrever Frehtes Taifersar Arahesis]

[-- Attachment #1: Type: Text/Plain, Size: 801 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[David Leverton]

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.

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

[Paul de Vrieze]

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

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

[Christian Faulhammer]

[-- Attachment #1: Type: text/plain, Size: 2340 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]