[gentoo-dev] Defining the Tree: a proto-GLEP.

[gentoo-dev] Defining the Tree: a proto-GLEP.

[Stephen Bennett]

Continuing in the series of issues raised during the previous package
manager discussions, I'd like to continue by mentioning the tree
format. At present, it isn't defined beyond "what the current portage
supports", which is frankly a fairly silly way to do things. Following
discussion in #gentoo-portage, I'd like to set out to change that.

My current idea is to draw up a formal specification of what ebuilds
are allowed to do, and what to assume about the environment in which
they run, as well as defining the formats of everything under
profiles/, metadata.xml files, and other auxiliary information in the
tree. I would envision the first version of this document to more or
less codify existing practise, perhaps excluding some dubious tricks
that are known to break in some cases. Generally, it should be possible
to make the tree conform to the first version of the specification by
changes no more significant than currently have QA bugs filed for them.

It seems fairly obvious that any effort of this kind could potentially
have implications, albeit hopefully very minor, across more or less all
aspects of the tree, and so I'd like to seek as wide a range of input
as possible before going ahead with it. The QA and Portage teams, based
on my enquiries in IRC, seem broadly in favour, and I would imagine
that this could be very helpful to Gentoo/ALT as well, so I'd like
opinions from others at this point. Would you support such an effort,
whether passively or actively? Would you oppose it? If so, why? Final
implementation of it would I assume require the Council's approval;
while I won't ask at this stage for a formal discussion I'd appreciate
the views of its members on whether such an initiative is likely to
pass.

Any input is gratefully received.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Defining the Tree: a proto-GLEP.

[Luis Francisco Araujo]

Stephen Bennett wrote:
> Continuing in the series of issues raised during the previous package
> manager discussions, I'd like to continue by mentioning the tree
> format. At present, it isn't defined beyond "what the current portage
> supports", which is frankly a fairly silly way to do things. Following
> discussion in #gentoo-portage, I'd like to set out to change that.
>
> My current idea is to draw up a formal specification of what ebuilds
> are allowed to do, and what to assume about the environment in which
> they run, as well as defining the formats of everything under
> profiles/, metadata.xml files, and other auxiliary information in the
> tree. I would envision the first version of this document to more or
> less codify existing practise, perhaps excluding some dubious tricks
> that are known to break in some cases. Generally, it should be possible
> to make the tree conform to the first version of the specification by
> changes no more significant than currently have QA bugs filed for them.
>
> It seems fairly obvious that any effort of this kind could potentially
> have implications, albeit hopefully very minor, across more or less all
> aspects of the tree, and so I'd like to seek as wide a range of input
> as possible before going ahead with it. The QA and Portage teams, based
> on my enquiries in IRC, seem broadly in favour, and I would imagine
> that this could be very helpful to Gentoo/ALT as well, so I'd like
> opinions from others at this point. Would you support such an effort,
> whether passively or actively? Would you oppose it? If so, why? Final
> implementation of it would I assume require the Council's approval;
> while I won't ask at this stage for a formal discussion I'd appreciate
> the views of its members on whether such an initiative is likely to
> pass.
>
> Any input is gratefully received.
>   
I like the idea. This would be some kind of portage-tree standard?
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Defining the Tree: a proto-GLEP.

[Stephen Bennett]

On Mon, 12 Jun 2006 19:04:39 -0400
Luis Francisco Araujo <araujo@gentoo.org> wrote:

> I like the idea. This would be some kind of portage-tree standard?

This would be, in essence, a formal definition of the layout of the
tree, and the format of and assumptions made by every file contained
within it.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Defining the Tree: a proto-GLEP.

[Luca Barbato]

Stephen Bennett wrote:

> This would be, in essence, a formal definition of the layout of the
> tree, and the format of and assumptions made by every file contained
> within it.

I'm all for it.

lu

-- 

Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Defining the Tree: a proto-GLEP.

[Henrik Brix Andersen]

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

On Tue, Jun 13, 2006 at 01:26:39AM +0200, Luca Barbato wrote:
> Stephen Bennett wrote:
> 
> > This would be, in essence, a formal definition of the layout of the
> > tree, and the format of and assumptions made by every file contained
> > within it.
> 
> I'm all for it.

Definately. Go for it.

Regards,
Brix
-- 
Henrik Brix Andersen <brix@gentoo.org>
Gentoo Metadistribution | Mobile computing herd

[-- Attachment #2: Type: application/pgp-signature, Size: 213 bytes --]

Re: [gentoo-dev] Defining the Tree: a proto-GLEP.

[Luis Francisco Araujo]

Stephen Bennett wrote:
> On Mon, 12 Jun 2006 19:04:39 -0400
> Luis Francisco Araujo <araujo@gentoo.org> wrote:
>
>   
>> I like the idea. This would be some kind of portage-tree standard?
>>     
>
> This would be, in essence, a formal definition of the layout of the
> tree, and the format of and assumptions made by every file contained
> within it.
>   
Thanks, i do like the idea.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Defining the Tree: a proto-GLEP.

[Daniel Ostrow]

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

On Mon, 2006-06-12 at 19:04 -0400, Luis Francisco Araujo wrote:
> Stephen Bennett wrote:
> > Continuing in the series of issues raised during the previous package
> > manager discussions, I'd like to continue by mentioning the tree
> > format. At present, it isn't defined beyond "what the current portage
> > supports", which is frankly a fairly silly way to do things. Following
> > discussion in #gentoo-portage, I'd like to set out to change that.
> >
> > My current idea is to draw up a formal specification of what ebuilds
> > are allowed to do, and what to assume about the environment in which
> > they run, as well as defining the formats of everything under
> > profiles/, metadata.xml files, and other auxiliary information in the
> > tree. I would envision the first version of this document to more or
> > less codify existing practise, perhaps excluding some dubious tricks
> > that are known to break in some cases. Generally, it should be possible
> > to make the tree conform to the first version of the specification by
> > changes no more significant than currently have QA bugs filed for them.
> >
> > It seems fairly obvious that any effort of this kind could potentially
> > have implications, albeit hopefully very minor, across more or less all
> > aspects of the tree, and so I'd like to seek as wide a range of input
> > as possible before going ahead with it. The QA and Portage teams, based
> > on my enquiries in IRC, seem broadly in favour, and I would imagine
> > that this could be very helpful to Gentoo/ALT as well, so I'd like
> > opinions from others at this point. Would you support such an effort,
> > whether passively or actively? Would you oppose it? If so, why? Final
> > implementation of it would I assume require the Council's approval;
> > while I won't ask at this stage for a formal discussion I'd appreciate
> > the views of its members on whether such an initiative is likely to
> > pass.
> >
> > Any input is gratefully received.
> >   
> I like the idea. This would be some kind of portage-tree standard?

It's been one of the missing cornerstones of the whole equation. Lets
get it done and get it done right.

One thing I do ask...Lets all start now getting used to calling the
"portage tree" something different. I'm all for terms like "the tree" or
"the ebuild tree" or "the package tree" but at this point, given the
prompting subject matter, the idea of it being a tree which belongs to
portage seems outdated. This may seem like a small thing (like the teams
vs. herds argument that has been brought up countless times before) but
it is the silly little things like this that really do lower the mental
bar for new and exciting things to happen.

Thanks,

--Dan

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

Re: [gentoo-dev] Defining the Tree: a proto-GLEP.

[Alec Warner]

Daniel Ostrow wrote:
> On Mon, 2006-06-12 at 19:04 -0400, Luis Francisco Araujo wrote:
> 
>>Stephen Bennett wrote:
>>
>>>Continuing in the series of issues raised during the previous package
>>>manager discussions, I'd like to continue by mentioning the tree
>>>format. At present, it isn't defined beyond "what the current portage
>>>supports", which is frankly a fairly silly way to do things. Following
>>>discussion in #gentoo-portage, I'd like to set out to change that.
>>>
>>>My current idea is to draw up a formal specification of what ebuilds
>>>are allowed to do, and what to assume about the environment in which
>>>they run, as well as defining the formats of everything under
>>>profiles/, metadata.xml files, and other auxiliary information in the
>>>tree. I would envision the first version of this document to more or
>>>less codify existing practise, perhaps excluding some dubious tricks
>>>that are known to break in some cases. Generally, it should be possible
>>>to make the tree conform to the first version of the specification by
>>>changes no more significant than currently have QA bugs filed for them.
>>>
>>>It seems fairly obvious that any effort of this kind could potentially
>>>have implications, albeit hopefully very minor, across more or less all
>>>aspects of the tree, and so I'd like to seek as wide a range of input
>>>as possible before going ahead with it. The QA and Portage teams, based
>>>on my enquiries in IRC, seem broadly in favour, and I would imagine
>>>that this could be very helpful to Gentoo/ALT as well, so I'd like
>>>opinions from others at this point. Would you support such an effort,
>>>whether passively or actively? Would you oppose it? If so, why? Final
>>>implementation of it would I assume require the Council's approval;
>>>while I won't ask at this stage for a formal discussion I'd appreciate
>>>the views of its members on whether such an initiative is likely to
>>>pass.
>>>
>>>Any input is gratefully received.
>>>  
>>
>>I like the idea. This would be some kind of portage-tree standard?
> 
> 
> It's been one of the missing cornerstones of the whole equation. Lets
> get it done and get it done right.
> 
> One thing I do ask...Lets all start now getting used to calling the
> "portage tree" something different. I'm all for terms like "the tree" or
> "the ebuild tree" or "the package tree" but at this point, given the
> prompting subject matter, the idea of it being a tree which belongs to
> portage seems outdated. This may seem like a small thing (like the teams
> vs. herds argument that has been brought up countless times before) but
> it is the silly little things like this that really do lower the mental
> bar for new and exciting things to happen.
> 

I prefer gentoo-x86, although others hate that x86-centric moniker ;)

> Thanks,
> 
> --Dan

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Defining the Tree: a proto-GLEP.

[Luca Barbato]

Alec Warner wrote:
> 
> I prefer gentoo-x86, although others hate that x86-centric moniker ;)
> 

ebuilds' tree could be ok (now after the transgender cow Larry we greet
the transgenic fruits that grown on trees but have to be herded: the
Ebuilds!)

Ok, I should not post after midnight, local time...

lu

-- 

Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Defining the Tree: a proto-GLEP.

[Duncan]

Luca Barbato <lu_zero@gentoo.org> posted 448E1480.6020307@gentoo.org,
excerpted below, on  Tue, 13 Jun 2006 03:27:28 +0200:

> Alec Warner wrote:
>> 
>> I prefer gentoo-x86, although others hate that x86-centric moniker ;)
>> 
>> 
> ebuilds' tree could be ok (now after the transgender cow Larry we greet
> the transgenic fruits that grown on trees but have to be herded: the
> Ebuilds!)
> 
> Ok, I should not post after midnight, local time...

I don't know... the idea seems to fit in perfectly with the idiosyncratic
Larry the cow, the mystery of the UFO guy, etc.  Come up with some sort of
tree graphic and the next step is a wallpaper with Larry under the tree,
and the UFO guy in the background... and the Gentoo logo, of course!  =8^)
Something like that would be great to run at the various conference Gentoo
booths, and I can envision myself running it as well.

To the topic at hand, however...  IMO, we need to choose a name, or rather
two of them, that address and make unambiguous the difference between the
overall package manager tree (including all the overlays and multiple
repositories that may exist on a local instance), and the official Gentoo
tree (which Alec referred to as gentoo-x86, correct if not now accurate,
due to history).  Disambiguating between the two should prove very
useful/helpful/dis-confusing, and choosing names that are clear both to
users and devs (unlike gentoo-x86, which can be quite confusing to a user)
will reduce confusion on bugzilla and the like, as well.

Unfortunately, I don't have any good suggestions, but I'm sure others can
come up with some.  =8^)



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

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Defining the Tree: a proto-GLEP.

[Andrej Kacian]

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

On Mon, 12 Jun 2006 20:14:02 -0400
Daniel Ostrow <dostrow@gentoo.org> wrote:

> One thing I do ask...Lets all start now getting used to calling the
> "portage tree" something different. I'm all for terms like "the tree" or
> "the ebuild tree" or "the package tree" but at this point, given the
> prompting subject matter, the idea of it being a tree which belongs to
> portage seems outdated. This may seem like a small thing (like the teams
> vs. herds argument that has been brought up countless times before) but
> it is the silly little things like this that really do lower the mental
> bar for new and exciting things to happen.

On related note, why "virtual/portage" ? Why not "virtual/packagemanager", or
something like that?

-- 
Andrej "Ticho" Kacian <ticho at gentoo dot org>
Gentoo Linux Developer - net-mail, antivirus, sound, x86

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

Re: [gentoo-dev] Defining the Tree: a proto-GLEP.

[Ned Ludd]

On Tue, 2006-06-13 at 13:38 +0200, Andrej Kacian wrote:

> On related note, why "virtual/portage" ? Why not "virtual/packagemanager", or
> something like that?

Because it already exists and is the least intrusive change. bug #69208

-- 
Ned Ludd <solar@gentoo.org>
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Defining the Tree: a proto-GLEP.

[Chris Gianelloni]

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

On Mon, 2006-06-12 at 20:14 -0400, Daniel Ostrow wrote:
> One thing I do ask...Lets all start now getting used to calling the
> "portage tree" something different. I'm all for terms like "the tree" or
> "the ebuild tree" or "the package tree" but at this point, given the
> prompting subject matter, the idea of it being a tree which belongs to
> portage seems outdated. This may seem like a small thing (like the teams
> vs. herds argument that has been brought up countless times before) but
> it is the silly little things like this that really do lower the mental
> bar for new and exciting things to happen.

I suggest we start calling it "Larry's tree" and be done with it.

Also, I am definitely for having an actual written standard for what
defines an ebuild.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

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

Re: [gentoo-dev] Defining the Tree: a proto-GLEP.

[Marius Mauch]

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

On Tue, 13 Jun 2006 00:00:43 +0100
Stephen Bennett <spb@gentoo.org> wrote:

> My current idea is to draw up a formal specification of what ebuilds
> are allowed to do, and what to assume about the environment in which
> they run, as well as defining the formats of everything under
> profiles/, metadata.xml files, and other auxiliary information in the
> tree. I would envision the first version of this document to more or
> less codify existing practise, perhaps excluding some dubious tricks
> that are known to break in some cases. Generally, it should be
> possible to make the tree conform to the first version of the
> specification by changes no more significant than currently have QA
> bugs filed for them.

Actually for the last two weeks or so (or whenever that pkgmanager
compat/transition glep was brought up) I was considering creating a new
"espec" project for that. This is beyond the scope of a single document
IMO and a separate project for it would help a bit to keep it
independent from existing implementations.

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.

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

Re: [gentoo-dev] Defining the Tree: a proto-GLEP.

[Robin H. Johnson]

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

On Tue, Jun 13, 2006 at 12:00:43AM +0100, Stephen Bennett wrote:
> My current idea is to draw up a formal specification of what ebuilds
> are allowed to do, and what to assume about the environment in which
> they run, as well as defining the formats of everything under
> profiles/, metadata.xml files, and other auxiliary information in the
> tree. I would envision the first version of this document to more or
> less codify existing practise, perhaps excluding some dubious tricks
> that are known to break in some cases. Generally, it should be possible
> to make the tree conform to the first version of the specification by
> changes no more significant than currently have QA bugs filed for them.
+1 from my side.

I'd like to be involved in the Manifest side, and something I'm
presently working on I should hopefully post in 2-3 days will I hope
clarify a few items at once, mainly revolving around signing - please
don't comment now, wait until I post said rough proposals.

-- 
Robin Hugh Johnson
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 241 bytes --]

Re: [gentoo-dev] Defining the Tree: a proto-GLEP.

[Mike Frysinger]

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

On Monday 12 June 2006 19:00, Stephen Bennett wrote:
> My current idea is to draw up a formal specification

huge wang

this would simplify greatly the work required for people to develop a package 
manager compatible with Gentoo ebuilds
-mike

[-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] Defining the Tree: a proto-GLEP.

[Paul de Vrieze]

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

On Tuesday 13 June 2006 01:00, Stephen Bennett wrote:
> My current idea is to draw up a formal specification of what ebuilds
> are allowed to do, and what to assume about the environment in which
> they run, as well as defining the formats of everything under
> profiles/, metadata.xml files, and other auxiliary information in the
> tree. I would envision the first version of this document to more or
> less codify existing practise, perhaps excluding some dubious tricks
> that are known to break in some cases. Generally, it should be possible
> to make the tree conform to the first version of the specification by
> changes no more significant than currently have QA bugs filed for them.

Metadata.xml files are already formally defined in 
http://www.gentoo.org/proj/en/metastructure/herds/#doc_chap4

You are welcome to extend/copy this information. Otherwise, go ahead. I don't 
see problems with codifying what ebuilds are allowed and not allowed to do.

Paul

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

[-- Attachment #2: Type: application/pgp-signature, Size: 200 bytes --]