Mailing List Archive

On Wednesday 01 March 2006 19:19, Ciaran McCreesh wrote:
> Unless there are any huge flaws found, I'd like this to be voted on by
> the council -- looks like it'll have to wait until April's meeting to
> fit in with the two weeks rule.

may push council meeting back to 3rd tuesday if people wish
-mike
--
gentoo-dev@gentoo.org mailing list

Mike Frysinger wrote:

>On Wednesday 01 March 2006 19:19, Ciaran McCreesh wrote:
>
>
>>Unless there are any huge flaws found, I'd like this to be voted on by
>>the council -- looks like it'll have to wait until April's meeting to
>>fit in with the two weeks rule.
>>
>>
>
>may push council meeting back to 3rd tuesday if people wish
>-mike
>
>
Is this a resubmission? Or would it be the first time this GLEP is being
presented to the council?
Regards, Andrew
--
gentoo-dev@gentoo.org mailing list

Mike Frysinger wrote:
> On Wednesday 01 March 2006 19:19, Ciaran McCreesh wrote:
>> Unless there are any huge flaws found, I'd like this to be voted on by
>> the council -- looks like it'll have to wait until April's meeting to
>> fit in with the two weeks rule.
>
> may push council meeting back to 3rd tuesday if people wish

I'd certainly like to see GLEP 42 addressed this month, if at all
possible. That said, the two-weeks rule is to avoid inconveniencing the
Council and unfairly springing something upon the devs without a chance
to look at the details. It's certainly a good rule, but I don't think
it should be considered inviolable. If there is an emergency, or the
issue is sufficiently well known that the entire two weeks notice seems
unnecessary, then I would think the Council could decide to make an
exception.

-g2boojum-

On Thu, 2 Mar 2006 00:19:47 +0000
Ciaran McCreesh <ciaranm@gentoo.org> wrote:

> Attached is the final draft. No substantial changes since last time,
> just wording cleanups and a few clarifications. You'll be able to see
> it here in an hour or three (check the dates!):
>
> http://www.gentoo.org/proj/en/glep/glep-0042.html
>
> Or you can try to read the attached RST source, but no moaning that it
> looks weird if you do.
>
> Unless there are any huge flaws found, I'd like this to be voted on by
> the council -- looks like it'll have to wait until April's meeting to
> fit in with the two weeks rule.

Nothing major, just a few minor issues (I'll admit I'm late):
"* Portage must extend portageq to implement a command which
returns whether or not the profile used for a given repository ID
matches a certain base path (e.g. portageq profile_used
default-linux/sparc/sparc64/2004.3 gentoo-x86)."
Wording here is a bit unclear, I assume it's supposed to mean wether or
not the (any) used profile belongs the the given repoid and is (a
subprofile of) the given profile name. Using "path" here is dangerous,
e.g. portageq profile_used base gentoo-x86.

As any substantial change results in a new news item should there be an
optional "Obsoletes" header? Could be used to make sure people only see
the most current version (without relying on rsync to wipe deleted
files).

Marius

--
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.
--
gentoo-dev@gentoo.org mailing list

On Sat, 4 Mar 2006 05:20:06 +0000 Marius Mauch <genone@gentoo.org>
wrote:
| "* Portage must extend portageq to implement a command which
| returns whether or not the profile used for a given repository ID
| matches a certain base path (e.g. portageq profile_used
| default-linux/sparc/sparc64/2004.3 gentoo-x86)."
| Wording here is a bit unclear, I assume it's supposed to mean wether
| or not the (any) used profile belongs the the given repoid and is (a
| subprofile of) the given profile name. Using "path" here is dangerous,
| e.g. portageq profile_used base gentoo-x86.

Hm, that one needs clarifying. Do we even want it to be based upon
inherit path rather than filesystem path?

| As any substantial change results in a new news item should there be
| an optional "Obsoletes" header? Could be used to make sure people
| only see the most current version (without relying on rsync to wipe
| deleted files).

I'd really rather not. That makes writing clients a lot harder.

--
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail : ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm

On Mon, 6 Mar 2006 01:09:58 +0000 Marius Mauch <genone@gentoo.org>
wrote:
| > Hm, that one needs clarifying. Do we even want it to be based upon
| > inherit path rather than filesystem path?
|
| If this is intended to replace deprected files one day I think we want
| (implementation isn't the problem one way or the other btw).

Except... That deprecated isn't inherited, and with good reason.
There's been at least one instance where we've wanted to move users
onto one of several subprofiles of a profile. I forget whether it was
actually used in the end and I'm too lazy to check, but the way this
was going to be handled was by deprecating the parent profile with a
message telling the users to select the correct subprofile.

| > | As any substantial change results in a new news item should there
| > | be an optional "Obsoletes" header? Could be used to make sure
| > | people only see the most current version (without relying on
| > | rsync to wipe deleted files).
| >
| > I'd really rather not. That makes writing clients a lot harder.
|
| It does? Just requires them to parse news items upfront and then
| remove all items matched by an Obsoletes header from the processing
| queue. Doesn't seem so tricky.

That's exactly it. It requires a client to look at and be able to
handle all other news items just to read a single item.

--
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail : ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm

On Sat, 4 Mar 2006 18:05:35 +0000
Ciaran McCreesh <ciaranm@gentoo.org> wrote:

> On Sat, 4 Mar 2006 05:20:06 +0000 Marius Mauch <genone@gentoo.org>
> wrote:
> | "* Portage must extend portageq to implement a command which
> | returns whether or not the profile used for a given repository ID
> | matches a certain base path (e.g. portageq profile_used
> | default-linux/sparc/sparc64/2004.3 gentoo-x86)."
> | Wording here is a bit unclear, I assume it's supposed to mean wether
> | or not the (any) used profile belongs the the given repoid and is (a
> | subprofile of) the given profile name. Using "path" here is
> dangerous, | e.g. portageq profile_used base gentoo-x86.
>
> Hm, that one needs clarifying. Do we even want it to be based upon
> inherit path rather than filesystem path?

If this is intended to replace deprected files one day I think we want
(implementation isn't the problem one way or the other btw).

> | As any substantial change results in a new news item should there be
> | an optional "Obsoletes" header? Could be used to make sure people
> | only see the most current version (without relying on rsync to wipe
> | deleted files).
>
> I'd really rather not. That makes writing clients a lot harder.

It does? Just requires them to parse news items upfront and then remove
all items matched by an Obsoletes header from the processing queue.
Doesn't seem so tricky.

Marius

--
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.
--
gentoo-dev@gentoo.org mailing list

On Thu, 2 Mar 2006 00:19:47 +0000 Ciaran McCreesh <ciaranm@gentoo.org>
wrote:
| Attached is the final draft.

And now, attached is the final final draft. The only change in this
version is to the behaviour of Display-If-Profile / `portageq
profile_used` -- now, an exact profile equivalence is used.

--
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail : ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm

On Monday 06 March 2006 01:19, Ciaran McCreesh wrote:
>
> That's exactly it. It requires a client to look at and be able to
> handle all other news items just to read a single item.

Who says that the client should do this? In my opinion doing so is an
improvement of the user experience, but not required. In any way, the biggest
use of the header is for unread items.

In general if you don't add the header, adding it later is a lot harder.

Paul

--
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

On Mon, 6 Mar 2006 11:37:09 +0100 Paul de Vrieze <pauldv@gentoo.org>
wrote:
| On Monday 06 March 2006 01:19, Ciaran McCreesh wrote:
| > That's exactly it. It requires a client to look at and be able to
| > handle all other news items just to read a single item.
|
| Who says that the client should do this?

If the client doesn't, there's a good chance some users will see two
versions of the same news item, and then things will get verrrryyy
confusing...

--
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail : ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm