[gentoo-pms] tree-layout.tex small cleanup

[gentoo-pms] tree-layout.tex small cleanup

[Patrick Lauer]

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

Three small edits.

- Removing a sentence that has no content, but spans three lines

- Simplifying the ebuild naming - since suffix is always "ebuild" there is no 
need to use an indirection

- Fixing the list because "suffix is ebuild" now is redundant

Four lines less and better readability.

Have fun,

Patrick

[-- Attachment #2: pms-make-things-readable.patch --]
[-- Type: text/x-patch, Size: 1283 bytes --]

diff --git a/tree-layout.tex b/tree-layout.tex
index b78fde2..b264779 100644
--- a/tree-layout.tex
+++ b/tree-layout.tex
@@ -40,10 +40,6 @@ specification. Additional directories that are not for a package may \i{not} be
 conflicts with package name directories; an exception is made for filesystem components whose name
 starts with a dot, which the package manager must ignore, and for any directory named \t{CVS}.

-It is not required that a directory exists for each category provided by the repository. A category
-directory that does not exist shall be considered equivalent to an empty category (and by extension,
-a package manager may treat an empty category as a category that does not exist).
-
 \section{Package Directories}
 \label{sec:package-dirs}

@@ -57,20 +53,18 @@ A package directory contains the following:
 \item A \t{files} directory, containing any support files needed by the ebuilds. Optional.
 \end{compactitem}

-Any ebuild in a package directory must be named \t{name-ver.suffix}, where:
+Any ebuild in a package directory must be named \t{name-ver.ebuild}, where:

 \begin{compactitem}
 \item \t{name} is the (unqualified) package name.
 \item \t{ver} is the package's version.
-\item \label{file-extension} \t{suffix} is \t{ebuild}.
 \end{compactitem}

Re: [gentoo-pms] tree-layout.tex small cleanup

[Ciaran McCreesh]

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

On Sat, 19 Sep 2009 22:15:40 +0200
Patrick Lauer <patrick@gentoo.org> wrote:
> Three small edits.
> 
> - Removing a sentence that has no content, but spans three lines

No, the two sentences you're removing both have meaning:

The first says that it's ok for things to exist in profiles/categories
that don't have a directory.

The second says that the package manager mustn't treat empty categories
and categories that don't exist differently.

Both are necessary.

> - Simplifying the ebuild naming - since suffix is always "ebuild"
> there is no need to use an indirection
> 
> - Fixing the list because "suffix is ebuild" now is redundant

Uhm. That part of the patch doesn't apply, and the revision against
which you're basing it isn't in the repository. Where did you get
'b78fde2' from?

-- 
Ciaran McCreesh

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

Re: [gentoo-pms] tree-layout.tex small cleanup

[Patrick Lauer]

On Saturday 19 September 2009 22:25:41 Ciaran McCreesh wrote:
> On Sat, 19 Sep 2009 22:15:40 +0200
> 
> Patrick Lauer <patrick@gentoo.org> wrote:
> > Three small edits.
> >
> > - Removing a sentence that has no content, but spans three lines
> 
> No, the two sentences you're removing both have meaning:
> 
> The first says that it's ok for things to exist in profiles/categories
> that don't have a directory
Rationale for that?

> The second says that the package manager mustn't treat empty categories
> and categories that don't exist differently.
Not quite. What it says is that an empty and a non-existing category are 
equivalent, which doesn't explain how to treat them. Your current 
interpretation is already a large improvement.

> Both are necessary.
No, first one is confusing to read, second one is a tautology.
 
> > - Simplifying the ebuild naming - since suffix is always "ebuild"
> > there is no need to use an indirection
> >
> > - Fixing the list because "suffix is ebuild" now is redundant
> 
> Uhm. That part of the patch doesn't apply, and the revision against
> which you're basing it isn't in the repository. Where did you get
> 'b78fde2' from?
>
Oh. I have over 900 lines diff already. Just pulling out the obvious changes 
before moving on to the more subjective and debatable ones. 

Re: [gentoo-pms] tree-layout.tex small cleanup

[Ciaran McCreesh]

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

On Sat, 19 Sep 2009 22:34:39 +0200
> > > Three small edits.
> > >
> > > - Removing a sentence that has no content, but spans three lines
> > 
> > No, the two sentences you're removing both have meaning:
> > 
> > The first says that it's ok for things to exist in
> > profiles/categories that don't have a directory
>
> Rationale for that?

People have done it in the past. It's also something that ends up
happening if categories are removed but people are syncing using
something that doesn't remove empty directories or directories that
still contain editor-created backup files lying around.

> > The second says that the package manager mustn't treat empty
> > categories and categories that don't exist differently.
> Not quite. What it says is that an empty and a non-existing category
> are equivalent, which doesn't explain how to treat them. Your current 
> interpretation is already a large improvement.

The wording in PMS is sound, and says exactly what it needs to say. If
you'd like to propose clarifications to that wording that make it
easier to understand, feel free to do so, but the actual meaning
mustn't be changed.

> > Both are necessary.
>
> No, first one is confusing to read

How is it in any way confusing?

>, second one is a tautology.

It's not. It would be quite possible to write an implementation that
treats categories that don't exist as an error rather than an empty
category. We have to forbid such an implementation.

> > > - Simplifying the ebuild naming - since suffix is always "ebuild"
> > > there is no need to use an indirection
> > >
> > > - Fixing the list because "suffix is ebuild" now is redundant
> > 
> > Uhm. That part of the patch doesn't apply, and the revision against
> > which you're basing it isn't in the repository. Where did you get
> > 'b78fde2' from?
> >
> Oh. I have over 900 lines diff already. Just pulling out the obvious
> changes before moving on to the more subjective and debatable ones. 

If that 900 line diff is 'drop kdebuild', I suggest you don't bother. In
any case, please learn how to use 'git rebase' and only send patches
that are against current master -- even for patches that do apply, if
you're basing them upon unpublished changes, we can't use three way
merges when applying them.

-- 
Ciaran McCreesh

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

Re: [gentoo-pms] tree-layout.tex small cleanup

[Patrick Lauer]

On Saturday 19 September 2009 22:45:15 Ciaran McCreesh wrote:
> On Sat, 19 Sep 2009 22:34:39 +0200
> > > The second says that the package manager mustn't treat empty
> > > categories and categories that don't exist differently.
> >
> > Not quite. What it says is that an empty and a non-existing category
> > are equivalent, which doesn't explain how to treat them. Your current
> > interpretation is already a large improvement.
> 
> The wording in PMS is sound, and says exactly what it needs to say. If
> you'd like to propose clarifications to that wording that make it
> easier to understand, feel free to do so, but the actual meaning
> mustn't be changed.

"A packager manager should not treat empty categories and categories that 
don't exist differently. Both cases should not be treated as errors."

How's that? It's not circular and quite readable. And if you noticed I 
borrowed most of your interpretation.


> >, second one is a tautology.
> 
> It's not. It would be quite possible to write an implementation that
> treats categories that don't exist as an error rather than an empty
> category. We have to forbid such an implementation.
Then say so.
 
> If that 900 line diff is 'drop kdebuild', I suggest you don't bother.
Stop giving me ideas! That would be a rather sane change, as there's lots of 
cruft that was explicitly denied by council in it. Also makes editing a bit 
easier ...

> In
> any case, please learn how to use 'git rebase' and only send patches
> that are against current master -- even for patches that do apply, if
> you're basing them upon unpublished changes, we can't use three way
> merges when applying them.
Ah, that sucks. Is there any non-hellish way to use git then? 

Re: [gentoo-pms] tree-layout.tex small cleanup

[Ciaran McCreesh]

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

On Sat, 19 Sep 2009 22:56:52 +0200
Patrick Lauer <patrick@gentoo.org> wrote:
> > The wording in PMS is sound, and says exactly what it needs to say.
> > If you'd like to propose clarifications to that wording that make it
> > easier to understand, feel free to do so, but the actual meaning
> > mustn't be changed.
> 
> "A packager manager should not treat empty categories and categories
> that don't exist differently. Both cases should not be treated as
> errors."
> 
> How's that? It's not circular and quite readable. And if you noticed
> I borrowed most of your interpretation.

I'd take a patch for that (keeping or clarifying the original sentence),
although stylistically, "Neither case should be" is cleaner. Also, I
think we're supposed to be using 'must' over 'should', although most of
the existing language doesn't...

> > In
> > any case, please learn how to use 'git rebase' and only send patches
> > that are against current master -- even for patches that do apply,
> > if you're basing them upon unpublished changes, we can't use three
> > way merges when applying them.
> Ah, that sucks. Is there any non-hellish way to use git then? 

Do your changes on a private branch. Use either 'git cherry-pick'
or 'git rebase' to copy them onto either master or a 'to-submit'
branch, and create your format-patches from there. Use 'git rebase' to
sort your branches out if master changes in the mean time.

Note that git rebase is a swiss army chainsaw, and unless you
understand exactly what it does, it's fairly easy to lose limbs... The
'Git for Computer Scientists' article [1] is a pretty good way of
learning what's really going on.

[1]: http://eagain.net/articles/git-for-computer-scientists/

-- 
Ciaran McCreesh

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

Re: [gentoo-pms] tree-layout.tex small cleanup

[Ulrich Mueller]

>>>>> On Sat, 19 Sep 2009, Ciaran McCreesh wrote:

> If that 900 line diff is 'drop kdebuild', I suggest you don't
> bother.

Actually, I think that this would be a good idea. kdebuild was never
used in the main tree, and the conditionals needed for it only add
clutter that makes reading and editing the source more difficult.

Ulrich

Re: [gentoo-pms] tree-layout.tex small cleanup

[Ciaran McCreesh]

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

On Sun, 20 Sep 2009 00:03:34 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:
> >>>>> On Sat, 19 Sep 2009, Ciaran McCreesh wrote:
> > If that 900 line diff is 'drop kdebuild', I suggest you don't
> > bother.
> 
> Actually, I think that this would be a good idea. kdebuild was never
> used in the main tree

But it was an official Gentoo project, and it was used in a repository
run by the Gentoo KDE team. Remember that EAPI support is needed to be
able to uninstall a package that was installed with a particular EAPI,
so EAPIs can't be removed even when they're no longer in use.

> and the conditionals needed for it only add
> clutter that makes reading and editing the source more difficult.

Ok, so we remove the conditionals and just keep it in unconditionally.

Keeping it documented hurts no-one. It also reduces the amount of work
we have to do as features that it has slowly end up in
Portage-supported EAPIs -- EAPI 3 would have taken much longer had we
had to rewrite it all from scratch.

-- 
Ciaran McCreesh

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

Re: [gentoo-pms] tree-layout.tex small cleanup

[Andrew D Kirch]

Ciaran McCreesh wrote:
> On Sun, 20 Sep 2009 00:03:34 +0200
> Ulrich Mueller <ulm@gentoo.org> wrote:
>   
>>>>>>> On Sat, 19 Sep 2009, Ciaran McCreesh wrote:
>>>>>>>               
>>> If that 900 line diff is 'drop kdebuild', I suggest you don't
>>> bother.
>>>       
>> Actually, I think that this would be a good idea. kdebuild was never
>> used in the main tree
>>     
>
> But it was an official Gentoo project, and it was used in a repository
> run by the Gentoo KDE team. Remember that EAPI support is needed to be
> able to uninstall a package that was installed with a particular EAPI,
> so EAPIs can't be removed even when they're no longer in use.
I can't agree here.  While no process exists to remove deprecated EAPI
functionality, this sort of thing should be noted in the NEXT EAPI
RELEASED and via that method eliminated.  This is a specifications
document, not a history lesson covering past mistakes.

Andrew

Re: [gentoo-pms] tree-layout.tex small cleanup

[Ciaran McCreesh]

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

On Sat, 19 Sep 2009 18:31:22 -0400
Andrew D Kirch <trelane@trelane.net> wrote:
> > But it was an official Gentoo project, and it was used in a
> > repository run by the Gentoo KDE team. Remember that EAPI support
> > is needed to be able to uninstall a package that was installed with
> > a particular EAPI, so EAPIs can't be removed even when they're no
> > longer in use.
>
> I can't agree here.  While no process exists to remove deprecated EAPI
> functionality, this sort of thing should be noted in the NEXT EAPI
> RELEASED and via that method eliminated.

Please explain what you mean. EAPIs are conceptually independent, and
don't deprecate each other in any kind of way, and future EAPI
releases can't retroactively change what previous EAPIs said.

> This is a specifications document, not a history lesson covering past
> mistakes.

Getting off-topic here, but which parts of kdebuild-1 do you think were
mistakes? Given how kdebuild-1 features are making their way into EAPIs
2, 3 and beyond as Portage gains support for them, I'm sure you don't
mean that every feature was wrong, so which of the remaining ones do you
think shouldn't be adopted and why?

-- 
Ciaran McCreesh

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

Re: [gentoo-pms] tree-layout.tex small cleanup

[Ulrich Mueller]

>>>>> On Sat, 19 Sep 2009, Ciaran McCreesh wrote:

> But it was an official Gentoo project, [...]

The 2008-04-10 council summary says something different:

# The council voted that kdebuild-1 and other unapproved EAPIs could
# not be in an approved PMS document. The spec isn't a place for
# proposals or things that will never be submitted for approval by the
# council. It's a specification, a reference of what is allowed in the
# main tree.

So, really no need to discuss it further.

Ulrich

Re: [gentoo-pms] tree-layout.tex small cleanup

[Patrick Lauer]

> > > If that 900 line diff is 'drop kdebuild', I suggest you don't
> > > bother.
> >
> > Actually, I think that this would be a good idea. kdebuild was never
> > used in the main tree
> 
> But it was an official Gentoo project, and it was used in a repository
> run by the Gentoo KDE team.
So the Gentoo KDE team could decide to keep the documentation. As 
representative of the KDE team I say that we have no interest in keeping this 
historical error around any more. Especially as it never worked (well, not 
with portage at least), so none of our users would be affected.

Also, it was only official in the sense that the KDE team decided to start it, 
then abandon it and leave Gentoo. In the same sense package.mask as a 
directory is officially supported (used by the KDE team, temporarily removed 
for legacy package managers).

> Remember that EAPI support is needed to be
> able to uninstall a package that was installed with a particular EAPI,
> so EAPIs can't be removed even when they're no longer in use.
Yeah, like, uhm, yeah, no. See above.
> 
> > and the conditionals needed for it only add
> > clutter that makes reading and editing the source more difficult.
> 
> Ok, so we remove the conditionals and just keep it in unconditionally.
That would imply having it in the official version, which explicitly goes 
against a prior council decision. 

Remember the bash 3.0/3.2 change yesterday? Where you said you don't have the 
power to change it? Yeah, neither do you have it here ... adding kdebuild-1 
unconditionally is not an option.

> Keeping it documented hurts no-one.
I disagree. It makes accidental errors more likely (like having kdebuild 
enabled in a version that looks authorative) and makes editing a pain because 
most tables are redundant (in the sense that they aren't needed and in the 
sense that they are there twice to accomodate the kdebuild phantom)

It also doesn't document anything that is related to the main gentoo tree, so 
it makes no sense to keep it in the document that is supposed to document 
_that_.

> It also reduces the amount of work
> we have to do as features that it has slowly end up in
> Portage-supported EAPIs -- EAPI 3 would have taken much longer had we
> had to rewrite it all from scratch.
That assumes that there's any overlap between future EAPIs and kdebuild, which 
is quite optimistic.
 
So I say tag it and remove it, if anyone should be interested in archaeology 
(s)he can find the right point in the git repo easily and create a 
historically accurate representation of the Tyrannosaurus Rex. Err, 
kdebuild-1.


Have a nice day,

Patrick

Re: [gentoo-pms] tree-layout.tex small cleanup

[Ciaran McCreesh]

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

On Sun, 20 Sep 2009 00:43:35 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:
> >>>>> On Sat, 19 Sep 2009, Ciaran McCreesh wrote:
> 
> > But it was an official Gentoo project, [...]
> 
> The 2008-04-10 council summary says something different:
> 
> # The council voted that kdebuild-1 and other unapproved EAPIs could
> # not be in an approved PMS document. The spec isn't a place for
> # proposals or things that will never be submitted for approval by the
> # council. It's a specification, a reference of what is allowed in the
> # main tree.

Please point to where the Council said that the Gentoo KDE project
wasn't an official Gentoo project.

> So, really no need to discuss it further.

Sure there is. Let's look at what happens if you remove it:

* It makes it harder for package manager authors to deal with things
  that were delivered by an official Gentoo project.

* It makes doing future EAPIs more work, since we'll almost certainly
  end up rewriting things that we'd be taking out.

As much as you might like to rewrite history to pretend it never
existed, the fact is, kdebuild-1 did exist and we're better off
acknowledging that.

-- 
Ciaran McCreesh

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

Re: [gentoo-pms] tree-layout.tex small cleanup

[Ciaran McCreesh]

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

On Sun, 20 Sep 2009 00:48:51 +0200
Patrick Lauer <patrick@gentoo.org> wrote:
> In the same sense package.mask as a directory is officially supported
> (used by the KDE team, temporarily removed for legacy package
> managers).

Patrick, if you're going to keep trolling, kindly do so elsewhere.

Your response [1] to the rejection of your bash version patch shows
that you're not interested in getting your concerns fixed, and are
instead just trying to stir up trouble. Please find a different project
to harass; we've all got better things to do than deal with this.

[1] http://gentooexperimental.org/~patrick/weblog/archives/2009-09.html#e2009-09-19T23_23_22.txt

-- 
Ciaran McCreesh

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

Re: [gentoo-pms] tree-layout.tex small cleanup

[Patrick Lauer]

On Sunday 20 September 2009 00:54:38 Ciaran McCreesh wrote:
> On Sun, 20 Sep 2009 00:43:35 +0200
> 
> Ulrich Mueller <ulm@gentoo.org> wrote:
> > >>>>> On Sat, 19 Sep 2009, Ciaran McCreesh wrote:
> > >
> > > But it was an official Gentoo project, [...]
> >
> > The 2008-04-10 council summary says something different:
> >
> > # The council voted that kdebuild-1 and other unapproved EAPIs could
> > # not be in an approved PMS document. The spec isn't a place for
> > # proposals or things that will never be submitted for approval by the
> > # council. It's a specification, a reference of what is allowed in the
> > # main tree.
> 
> Please point to where the Council said that the Gentoo KDE project
> wasn't an official Gentoo project.

That is unrelated to the matter. Please stop trying to confuse the discussion 
when you run out of arguments.

The council statement is VERY clear and unambiguous. What other gentoo 
projects do on the side is their thing and not directly related to PMS (unless 
you intend to have the prefix project merge all their changes and new EAPIs 
into PMS?)

I am unsure how to classify your logical fallacy. It fits "non sequitur" and 
"ignoratio elenchi". Either way you know that it doesn't really belong there 
and was meant only to distract us. Which is quite rude ...

> > So, really no need to discuss it further.
> 
> Sure there is. Let's look at what happens if you remove it:
> 
> * It makes it harder for package manager authors to deal with things
>   that were delivered by an official Gentoo project.
Then they need to read that project's documentation. The genkdesvn project is 
free to split out their own PMS+kdebuild-1 fork.

The Gentoo KDE project does not care about it and does not, in any way, claim 
to support the kdebuild-1 EAPI. The "kdebuild-*" namespace in PMS, which was 
given to the KDE project, was even reserved for genkdesvn use because the KDE 
project has no need for it and doesn't want to deny the past. (We could have 
opted to have that namespace made unavailable instead ...)
 
> * It makes doing future EAPIs more work, since we'll almost certainly
>   end up rewriting things that we'd be taking out.
Irrelevant. Then we'll spend an hour more editing it. You'll even have my help 
doing it!

> As much as you might like to rewrite history to pretend it never
> existed, the fact is, kdebuild-1 did exist and we're better off
> acknowledging that.
We do. Just that PMS is not the place to document random experiments. The 
council has made it very clear how to handle that. So let the genkdesvn 
project document it as much as they want, noone else does want it.

Take care,

Patrick

Re: [gentoo-pms] tree-layout.tex small cleanup

[Ciaran McCreesh]

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

On Sun, 20 Sep 2009 01:07:25 +0200
Patrick Lauer <patrick@gentoo.org> wrote:
> > Ulrich Mueller <ulm@gentoo.org> wrote:
> > > >>>>> On Sat, 19 Sep 2009, Ciaran McCreesh wrote:
> > > > But it was an official Gentoo project, [...]
> > >
> > > The 2008-04-10 council summary says something different:
> > >
> > > # The council voted that kdebuild-1 and other unapproved EAPIs
> > > could # not be in an approved PMS document. The spec isn't a
> > > place for # proposals or things that will never be submitted for
> > > approval by the # council. It's a specification, a reference of
> > > what is allowed in the # main tree.
> > 
> > Please point to where the Council said that the Gentoo KDE project
> > wasn't an official Gentoo project.
> 
> That is unrelated to the matter. Please stop trying to confuse the
> discussion when you run out of arguments.

I made a claim, and Ulrich said that the Council disagreed. But the
decision he points to does not contradict the claim I made. It's
entirely related.

> The council statement is VERY clear and unambiguous. What other
> gentoo projects do on the side is their thing and not directly
> related to PMS (unless you intend to have the prefix project merge
> all their changes and new EAPIs into PMS?)

Sure. If the prefix project can put together a specification-quality
description of their work, and can guarantee the level of stability
that we need from EAPIs, I'd be happy to see it in PMS. It would be much
more useful for package manager authors to have it documented and well
defined.

> > > So, really no need to discuss it further.
> > 
> > Sure there is. Let's look at what happens if you remove it:
> > 
> > * It makes it harder for package manager authors to deal with things
> >   that were delivered by an official Gentoo project.
> Then they need to read that project's documentation. The genkdesvn
> project is free to split out their own PMS+kdebuild-1 fork.

Forks are a last resort. For package manager authors, having a single
source rather than two is much easier, and if it's possible to do
things that way then we should. Forks should only happen when there's
no other way of resolving it.

Why should we make PMS less useful for package manager developers?

-- 
Ciaran McCreesh

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

Re: [gentoo-pms] tree-layout.tex small cleanup

[Andrew D Kirch]

Ciaran McCreesh wrote:
> On Sat, 19 Sep 2009 18:31:22 -0400
> Andrew D Kirch <trelane@trelane.net> wrote:
>   
>>> But it was an official Gentoo project, and it was used in a
>>> repository run by the Gentoo KDE team. Remember that EAPI support
>>> is needed to be able to uninstall a package that was installed with
>>> a particular EAPI, so EAPIs can't be removed even when they're no
>>> longer in use.
>>>       
>> I can't agree here.  While no process exists to remove deprecated EAPI
>> functionality, this sort of thing should be noted in the NEXT EAPI
>> RELEASED and via that method eliminated.
>>     
>
> Please explain what you mean. EAPIs are conceptually independent, and
> don't deprecate each other in any kind of way, and future EAPI
> releases can't retroactively change what previous EAPIs said.
>   
There's no reason why a subsequent EAPI cannot modify or remove behavior
created in a previous EAPI.
>> This is a specifications document, not a history lesson covering past
>> mistakes.
>>     
>
> Getting off-topic here, but which parts of kdebuild-1 do you think were
> mistakes? Given how kdebuild-1 features are making their way into EAPIs
> 2, 3 and beyond as Portage gains support for them, I'm sure you don't
> mean that every feature was wrong, so which of the remaining ones do you
> think shouldn't be adopted and why?
>   
kdebuild itself wasn't a mistake, that it made it in when it's not used was.

Re: [gentoo-pms] tree-layout.tex small cleanup

[Patrick Lauer]

On Sunday 20 September 2009 01:03:41 Ciaran McCreesh wrote:
> On Sun, 20 Sep 2009 00:48:51 +0200
> 
> Patrick Lauer <patrick@gentoo.org> wrote:
> > In the same sense package.mask as a directory is officially supported
> > (used by the KDE team, temporarily removed for legacy package
> > managers).
> 
> Patrick, if you're going to keep trolling, kindly do so elsewhere.
Well, some facts - 

The KDE overlay used package.mask as a directory. Some users who had been 
migrated to paludis in the genkdesvn times complained. The KDE team decided to 
remove that nice feature to keep users happy, progress be damned. And most of 
the KDE team members wish to re-add that feature.

That ain't trolling, that be facts. 

> 
> Your response [1] to the rejection of your bash version patch
I fail to see what my blog has to do with discussing PMS and this mailinglist. 
Please stop confusing things by trying to throw in random unrelated things 
until people walk away in frustration and you win by being the bigger idiot.

> shows
> that you're not interested in getting your concerns fixed, and are
> instead just trying to stir up trouble.
I would say that documenting the current state of things is quite relevant to 
the issue at hand. If you are bothered by facts please don't try to engage in 
discussions.


> Please find a different project
> to harass; we've all got better things to do than deal with this.
I couldn't have said it better. I doubt you'll listen to your own advice 
though. Even after forking PMS[1] and throwing a tantrum. 

And here something completely unrelated:
<darkside_> bonsaikitten: you know the best part in response to your blog post 
is?
<darkside_> bonsaikitten: python.eclass uses "+=" in it, so portage can't be 
installed with bash-3.0 ;)

I couldn't have said it better. Stupid reality not obeying!


[1] http://archives.gentoo.org/gentoo-
pms/msg_d06ee6e4fdbd43f9129125daaae2ad14.xml

Re: [gentoo-pms] tree-layout.tex small cleanup

[Ciaran McCreesh]

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

On Sat, 19 Sep 2009 19:19:41 -0400
Andrew D Kirch <trelane@trelane.net> wrote:
> > Please explain what you mean. EAPIs are conceptually independent,
> > and don't deprecate each other in any kind of way, and future EAPI
> > releases can't retroactively change what previous EAPIs said.
> >   
> There's no reason why a subsequent EAPI cannot modify or remove
> behavior created in a previous EAPI.

If you mean "EAPIs don't have to include every feature that was
included in a previous EAPI, and can do things differently from
previous EAPIs" then sure. See, for example, dohard and dosed being
removed in EAPI 3.

If you mean that "EAPIs can change the meaning of older EAPIs", then
you're wildly misunderstanding how the whole thing works. We couldn't
use EAPI 3 to say that "it's illegal for EAPI 0, 1 and 2 things to use
dohard and dosed"; that would defeat half of the point of having EAPIs.

> >> This is a specifications document, not a history lesson covering
> >> past mistakes.
> >
> > Getting off-topic here, but which parts of kdebuild-1 do you think
> > were mistakes? Given how kdebuild-1 features are making their way
> > into EAPIs 2, 3 and beyond as Portage gains support for them, I'm
> > sure you don't mean that every feature was wrong, so which of the
> > remaining ones do you think shouldn't be adopted and why?
> >   
> kdebuild itself wasn't a mistake, that it made it in when it's not
> used was.

Explain please. kdebuild-1 was used.

-- 
Ciaran McCreesh

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

Re: [gentoo-pms] tree-layout.tex small cleanup

[Ciaran McCreesh]

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

On Sun, 20 Sep 2009 01:26:38 +0200
Patrick Lauer <patrick@gentoo.org> wrote:
> On Sunday 20 September 2009 01:03:41 Ciaran McCreesh wrote:
> > On Sun, 20 Sep 2009 00:48:51 +0200
> > 
> > Patrick Lauer <patrick@gentoo.org> wrote:
> > > In the same sense package.mask as a directory is officially
> > > supported (used by the KDE team, temporarily removed for legacy
> > > package managers).
> > 
> > Patrick, if you're going to keep trolling, kindly do so elsewhere.
> Well, some facts - 
> 
> The KDE overlay used package.mask as a directory. Some users who had
> been migrated to paludis in the genkdesvn times complained. The KDE
> team decided to remove that nice feature to keep users happy,
> progress be damned. And most of the KDE team members wish to re-add
> that feature.
> 
> That ain't trolling, that be facts. 

The KDE team are more than welcome to re-add it as an EAPI controlled
feature, either through EAPI 4 or through EAPI kdebuild-2 as they
prefer.

There's a huge difference between doing something as a published
standard and doing something that violates a published standard.

> > Your response [1] to the rejection of your bash version patch
> I fail to see what my blog has to do with discussing PMS and this
> mailinglist. Please stop confusing things by trying to throw in
> random unrelated things until people walk away in frustration and you
> win by being the bigger idiot.

You had a patch rejected that the PMS team has no authority to accept,
and were told how to raise the issue with the appropriate authorities
to get the change you requested made. Rather than doing so, you decided
to suggest on your blog that the PMS team were to blame for rejecting
it.

> > shows
> > that you're not interested in getting your concerns fixed, and are
> > instead just trying to stir up trouble.
> I would say that documenting the current state of things is quite
> relevant to the issue at hand. If you are bothered by facts please
> don't try to engage in discussions.

Then why don't you follow the process we told you about for getting it
fixed?

> And here something completely unrelated:
> <darkside_> bonsaikitten: you know the best part in response to your
> blog post is?
> <darkside_> bonsaikitten: python.eclass uses "+=" in it, so portage
> can't be installed with bash-3.0 ;)
> 
> I couldn't have said it better. Stupid reality not obeying!

Again, why don't you do what we suggested to get the problem fixed? Why
do you instead continue to whine about us not changing something we're
not allowed to change?

-- 
Ciaran McCreesh

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

Re: [gentoo-pms] tree-layout.tex small cleanup

[Patrick Lauer]

> > > > In the same sense package.mask as a directory is officially
> > > > supported (used by the KDE team, temporarily removed for legacy
> > > > package managers).
> > >
> > > Patrick, if you're going to keep trolling, kindly do so elsewhere.
> >
> > Well, some facts -
> >
> > The KDE overlay used package.mask as a directory. Some users who had
> > been migrated to paludis in the genkdesvn times complained. The KDE
> > team decided to remove that nice feature to keep users happy,
> > progress be damned. And most of the KDE team members wish to re-add
> > that feature.
> >
> > That ain't trolling, that be facts.
> 
> The KDE team are more than welcome to re-add it as an EAPI controlled
> feature, either through EAPI 4 or through EAPI kdebuild-2 as they
> prefer.
> 
> There's a huge difference between doing something as a published
> standard and doing something that violates a published standard.

Now you're being quite inconsistent. If you are in support of what the "old" 
KDE team / genkdesvn did (create their own standard in an overlay and 
experiment with it) then you must also be in support of the "new" kde team
doing the same.

So either kdebuild-1 was a bad thing (not approved by council, not even 
supported by any official package manager) or package.mask as a directory is a 
good thing (feature has been there since the Old Times, only used in an 
overlay, well documented, no compatibility issues)

Also, kdebuild-1 was used _before_ it was voted on by council (which doesn't 
seem to bother you because it was in an overlay) and never became an official 
standard (published yes, but that's irrelevant). So by your own logic using it 
was A Bad Thing To Do. Or you only attacked funtoo (and their use of 
package.mask) for personal reasons?

> You had a patch rejected that the PMS team has no authority to accept,
> and were told how to raise the issue with the appropriate authorities
> to get the change you requested made. Rather than doing so, you decided
> to suggest on your blog that the PMS team were to blame for rejecting
> it.
I find this interpretation quite interesting, but I'm not that much into 
postmodern existentialism. You should do a subjective interpretation based on 
dadaism or the school of dancing goats.

That being said I was merely pointing out that the statement in PMS ("bash 
version 3.0") has no base in reality anymore and has been de facto obsoleted. 
De jure the council has not voted against these violations, even when they 
were brought up quite a while ago (darkside claims 6-8 months ago).

So independent of what you believe in or desire the statement in PMS is WRONG. 
As such it needs to be corrected. 
If that happens on the short path by editing it directly or through the long 
path of letting council decide to have it edited doesn't matter to me, as long 
as PMS and reality can agree on basic things.

(And no, undoing all these modifications is not an option. It would positively 
cripple development for no reason, which might excite you, but it's not 
something the gentoo dev community will tolerate.)
 
> > I would say that documenting the current state of things is quite
> > relevant to the issue at hand. If you are bothered by facts please
> > don't try to engage in discussions.
> 
> Then why don't you follow the process we told you about for getting it
> fixed?

Well, it's on the council's agenda now. I would say that it's following 
process quite well. How about you don't ask questions you already know the 
answer to?
 
> > And here something completely unrelated:
> > <darkside_> bonsaikitten: you know the best part in response to your
> > blog post is?
> > <darkside_> bonsaikitten: python.eclass uses "+=" in it, so portage
> > can't be installed with bash-3.0 ;)
> >
> > I couldn't have said it better. Stupid reality not obeying!
> 
> Again, why don't you do what we suggested to get the problem fixed? Why
> do you instead continue to whine about us not changing something we're
> not allowed to change?
Ah, pluralis majestatis. Doesn't get you executed anymore these days.
So what else, apart from discussing it on this mailinglist and putting it on 
the council agenda should I have done? Collected my thoughts and made them 
into a blog post? Oh wait. 

Now I don't want to be a spoilsport, but you've consistently tried to derail 
this discussion, brought in irrelevant things and tried to confuse matters by 
adding in random stuff until everyone is confused. That's no way to discuss 
technical matters. If you can't stay on topic and avoid personal attacks we'll 
have to reconsider how to handle this situation. Le sigh.

Patrick

Re: [gentoo-pms] tree-layout.tex small cleanup

[Ciaran McCreesh]

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

On Sun, 20 Sep 2009 02:37:16 +0200
Patrick Lauer <patrick@gentoo.org> wrote:
> > The KDE team are more than welcome to re-add it as an EAPI
> > controlled feature, either through EAPI 4 or through EAPI
> > kdebuild-2 as they prefer.
> > 
> > There's a huge difference between doing something as a published
> > standard and doing something that violates a published standard.
> 
> Now you're being quite inconsistent. If you are in support of what
> the "old" KDE team / genkdesvn did (create their own standard in an
> overlay and experiment with it) then you must also be in support of
> the "new" kde team doing the same.

If they do it as a published standard, yes, I'm entirely in favour of
it and would be happy to provide any assistance they require. If they do
it without proper EAPI markings and as an undocumented extension, then
no, I don't approve.

> So either kdebuild-1 was a bad thing (not approved by council, not
> even supported by any official package manager) or package.mask as a
> directory is a good thing (feature has been there since the Old
> Times, only used in an overlay, well documented, no compatibility
> issues)

package.mask as a directory as an extension that breaks
specification-compliant package managers is bad. As a documented,
standardised extension, it is good.

> Also, kdebuild-1 was used _before_ it was voted on by council (which
> doesn't seem to bother you because it was in an overlay) and never
> became an official standard (published yes, but that's irrelevant).
> So by your own logic using it was A Bad Thing To Do.

Published is entirely relevant. That it was approved by the KDE team
rather than the Council is not relevant, since it has no impact upon
anyone implementing a package manager.

> Or you only attacked funtoo (and their use of package.mask) for
> personal reasons?

I offered to help Funtoo do an EAPI funtoo-2 so they could use
package.mask as a directory. That offer remains open.

> I find this interpretation quite interesting, but I'm not that much
> into postmodern existentialism. You should do a subjective
> interpretation based on dadaism or the school of dancing goats.
> 
> That being said I was merely pointing out that the statement in PMS
> ("bash version 3.0") has no base in reality anymore and has been de
> facto obsoleted. De jure the council has not voted against these
> violations, even when they were brought up quite a while ago
> (darkside claims 6-8 months ago).

They also haven't given us permission to change PMS.

> So independent of what you believe in or desire the statement in PMS
> is WRONG. As such it needs to be corrected. 

PMS accurately reflects the most recent official decision from the
Council.

> If that happens on the short path by editing it directly or through
> the long path of letting council decide to have it edited doesn't
> matter to me, as long as PMS and reality can agree on basic things.

Then why have you still not followed the process to get the change
made? Why did you instead start blaming the PMS team for refusing to
exceed its authority?

> > > I would say that documenting the current state of things is quite
> > > relevant to the issue at hand. If you are bothered by facts please
> > > don't try to engage in discussions.
> > 
> > Then why don't you follow the process we told you about for getting
> > it fixed?
> 
> Well, it's on the council's agenda now. I would say that it's
> following process quite well. How about you don't ask questions you
> already know the answer to?

I've still not seen a thread discussing it on gentoo-dev@. Is there a
particular reason you're bypassing the normal process?

-- 
Ciaran McCreesh

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