[gentoo-dev] laying out arch profiles

[gentoo-dev] laying out arch profiles

[Mike Frysinger]

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

maintaining arch things across multiple operating systems is boring me so i'd 
like to start moving to profiles that outline arch-specific details

for example:
default-linux/parent:
	../base
default-linux/sh/parent:
	..
	../../arch/sh
arch/sh/parent:
	..
arch/parent -> none

all of the arch-specific details would be moved out of base/ and into arch/ 
(like altivec, sse, sse2, mmx, etc...) and then they can be unmasked in the 
respective arch/$arch/ subdir

this would be for 2007.1+ profiles and we can leave the old things in place 
until we phase out 2007.0 and older completely
-mike

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

Re: [gentoo-dev] laying out arch profiles

[Chris Gianelloni]

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

On Wed, 2007-06-27 at 12:31 -0400, Mike Frysinger wrote:
> maintaining arch things across multiple operating systems is boring me so i'd 
> like to start moving to profiles that outline arch-specific details
> 
> for example:
> default-linux/parent:
> 	../base
> default-linux/sh/parent:
> 	..
> 	../../arch/sh
> arch/sh/parent:
> 	..
> arch/parent -> none
> 
> all of the arch-specific details would be moved out of base/ and into arch/ 
> (like altivec, sse, sse2, mmx, etc...) and then they can be unmasked in the 
> respective arch/$arch/ subdir
> 
> this would be for 2007.1+ profiles and we can leave the old things in place 
> until we phase out 2007.0 and older completely

This is actually something I was already planning on working on setting
up.  To avoid conflicting with the current profiles, I was planning on
making a new profile tree.  I wasn't planning on using it for 2007.1's
official media, though, but rather just /experimental stuff, since I'd
rather get much more testing on it before it goes "live" as the default.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

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

Re: [gentoo-dev] laying out arch profiles

[Mike Frysinger]

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

On Thursday 05 July 2007, Chris Gianelloni wrote:
> On Wed, 2007-06-27 at 12:31 -0400, Mike Frysinger wrote:
> > maintaining arch things across multiple operating systems is boring me so
> > i'd like to start moving to profiles that outline arch-specific details
> >
> > for example:
> > default-linux/parent:
> > 	../base
> > default-linux/sh/parent:
> > 	..
> > 	../../arch/sh
> > arch/sh/parent:
> > 	..
> > arch/parent -> none
> >
> > all of the arch-specific details would be moved out of base/ and into
> > arch/ (like altivec, sse, sse2, mmx, etc...) and then they can be
> > unmasked in the respective arch/$arch/ subdir
> >
> > this would be for 2007.1+ profiles and we can leave the old things in
> > place until we phase out 2007.0 and older completely
>
> This is actually something I was already planning on working on setting
> up.  To avoid conflicting with the current profiles, I was planning on
> making a new profile tree.  I wasn't planning on using it for 2007.1's
> official media, though, but rather just /experimental stuff, since I'd
> rather get much more testing on it before it goes "live" as the default.

you proposing we rearchitect it all or just for testing purposes before going 
live ?  i can see both ...
profiles/frags/
  libc/uclibc/
  libc/gclibc/
  arch/amd64/
  arch/sh/
  kernel/linux/
  kernel/bsd/
  kernel/bsd/freebsd/
  kernel/bsd/openbsd/

profiles/default-linux/amd64/parent
  ../../frags/arch/amd64
  ../../frags/kernel/linux
  ../../frags/libc/glibc
  ..
-mike

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

[gentoo-dev] Re: laying out arch profiles

[Steve Long]

Mike Frysinger wrote:
>> > this would be for 2007.1+ profiles and we can leave the old things in
>> > place until we phase out 2007.0 and older completely
>>
>> This is actually something I was already planning on working on setting
>> up.  To avoid conflicting with the current profiles, I was planning on
>> making a new profile tree.  I wasn't planning on using it for 2007.1's
>> official media, though, but rather just /experimental stuff, since I'd
>> rather get much more testing on it before it goes "live" as the default.
> 
> you proposing we rearchitect it all or just for testing purposes before
> going live ?
Er I thought the whole point of a portage tree on the system was to allow
people to mess about with stuff.. Even if not, is there any real conflict
in doing both; ie rearchitect on an offline version, test properly and then
switch to new branch? However long releng need is however long they need
aiui. After the stress of the last few months, is it really such a big deal
if there's no 2007.1- it's not like anyone needs to reinstall is it?

Plus the difference between portage in 2006.0 and 2006.1 was a major bonus
for users. It might be simpler just to allow all the good stuff that's
being worked on now, and has already been discussed on this list, time to
come thru and bed down. After all, users only look stupid when we try and
install stuff that doesn't Just Work? especially after we've raved about
Gentoo, and got some poor schmuc^H^H^H^H *ahem* gained permission from the
relevant department to install ``rootkits behind the firewall''.[1]

Speaking of stuff that's holding you back, what's going on with the PMS?
Aiui several changes to portage await EAPI=1 and i don't see any sign of
EAPI=0 being finalised. The cia project page shows no commits since April.
Has it switched to another src-tracker?

> i can see both ... 
> profiles/frags/
>   libc/uclibc/
>   libc/gclibc/
>   arch/amd64/
>   arch/sh/
>   kernel/linux/
>   kernel/bsd/
>   kernel/bsd/freebsd/
>   kernel/bsd/openbsd/
> 
> profiles/default-linux/amd64/parent
>   ../../frags/arch/amd64
>   ../../frags/kernel/linux
>   ../../frags/libc/glibc
>   ..

Makes a lot of sense when you lay it out like that. Is there a namespace
issue with profiles/{libc,arch,kernel}?



[1] `Do you want to install this program? [setup.exe]' - wfm ;)

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: laying out arch profiles

[Mike Frysinger]

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

On Friday 06 July 2007, Steve Long wrote:
> Mike Frysinger wrote:
> >> > this would be for 2007.1+ profiles and we can leave the old things in
> >> > place until we phase out 2007.0 and older completely
> >>
> >> This is actually something I was already planning on working on setting
> >> up.  To avoid conflicting with the current profiles, I was planning on
> >> making a new profile tree.  I wasn't planning on using it for 2007.1's
> >> official media, though, but rather just /experimental stuff, since I'd
> >> rather get much more testing on it before it goes "live" as the default.
> >
> > you proposing we rearchitect it all or just for testing purposes before
> > going live ?
>
> Er I thought the whole point of a portage tree on the system was to allow
> people to mess about with stuff.. Even if not, is there any real conflict
> in doing both; ie rearchitect on an offline version, test properly and then
> switch to new branch? However long releng need is however long they need
> aiui. After the stress of the last few months, is it really such a big deal
> if there's no 2007.1- it's not like anyone needs to reinstall is it?

you misinterpret ... me saying "going live" means "release and expect people 
to switch to using it on stable systems"

> Speaking of stuff that's holding you back, what's going on with the PMS?
> Aiui several changes to portage await EAPI=1 and i don't see any sign of
> EAPI=0 being finalised. The cia project page shows no commits since April.
> Has it switched to another src-tracker?

nothing i'm prosing is held back by EAPI=1

> > i can see both ...
> > profiles/frags/
> >   libc/uclibc/
> >   libc/gclibc/
> >   arch/amd64/
> >   arch/sh/
> >   kernel/linux/
> >   kernel/bsd/
> >   kernel/bsd/freebsd/
> >   kernel/bsd/openbsd/
> >
> > profiles/default-linux/amd64/parent
> >   ../../frags/arch/amd64
> >   ../../frags/kernel/linux
> >   ../../frags/libc/glibc
> >   ..
>
> Makes a lot of sense when you lay it out like that. Is there a namespace
> issue with profiles/{libc,arch,kernel}?

i thought it looked ugly to have them in the top level.  the idea with frags 
is that by name only, it should be easy to see users arent supposed to be 
using the profile ...
-mike

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

Re: [gentoo-dev] laying out arch profiles

[Chris Gianelloni]

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

On Thu, 2007-07-05 at 18:47 -0400, Mike Frysinger wrote:
> you proposing we rearchitect it all or just for testing purposes before going 
> live ?  i can see both ...

I am proposing rethinking all of it.  My current thoughts run something
like this:

arch/amd64
arch/ppc (not ppc/ppc64 or ppc/ppc32)
base
default/linux
default/freebsd
default/macos
kernel/darwin
kernel/linux
kernel/freebsd
release/2007.1
target/desktop
target/server
userland (these aren't all the same type of thing)
userland/32-bit
userland/64-bit
userland/multilib
userland/freebsd
userland/hardened
userland/linux (this could be glibc, instead)
userland/macos
userland/no-nptl (not sure we really need this, at all)
userland/nptl (this either)
userland/selinux
userland/uclibc

Of course, this is just my rough outline.  What you would end up with,
as a profile, is something like this:

default/linux/amd64/2007.1/desktop (not much different from now)

default inherits from base, then determines the parent path we take,
such as glibc over uclibc
linux is simple in this case since we're "default" meaning we'll have a
Linux kernel and glibc userland
amd64 is the architecture, of course... being "default" means it'll be
multilib automatically... this level should be the "highest" usable
level with the least amount of USE/etc enabled, as it should be only
what is required globally plus arch-specific
2007.1 is the release-specific profile and adds in the
changes/enhancements from that particular release
desktop is the target the profile is designed for, so it would have
additional USE enabled

I would also love to use package sets in some way in the profiles for
defining sets of packages that might be useful to the user without
forcing them into the "system" set for that profile.  Some examples of
what I mean would be adding things like dhcpcd and gentoolkit to the
default "desktop" profile without them being in system, so they can be
easily removed by users that don't want them.  This would, of course,
depend on the implementation used for package sets.

Taking the above example, to build a hardened server, you'd have
something like:

hardened/linux/amd64/2007.1/server (again not much different)

Of course, this is all just how I've been envisioning doing everything
and I'm sure other people have lots of ideas on their own.

I'm creating an overlay for these profiles while I work on them, so we
can easily get input on them and track the changes.  I'd like to get
input on this schema for the profiles before I commit anything and am
definitely interested in getting input from anyone with any profile
experience.  Using an overlay will allow us to make changes (to base,
for example) without disrupting the tree until we're ready.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

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

Re: [gentoo-dev] laying out arch profiles

[Fabian Groffen]

On 09-07-2007 11:47:45 -0700, Chris Gianelloni wrote:
> On Thu, 2007-07-05 at 18:47 -0400, Mike Frysinger wrote:
> > you proposing we rearchitect it all or just for testing purposes before going 
> > live ?  i can see both ...
> 
> I am proposing rethinking all of it.  My current thoughts run something
> like this:

[snip]

> I'm creating an overlay for these profiles while I work on them, so we
> can easily get input on them and track the changes.  I'd like to get
> input on this schema for the profiles before I commit anything and am
> definitely interested in getting input from anyone with any profile
> experience.  Using an overlay will allow us to make changes (to base,
> for example) without disrupting the tree until we're ready.

While you're at it, in my own garden[1] I use some profile structure as
well.  This is not relevant to the big public, I guess.  However, might
be worth to keep it in the back of your head when designing new profile
structures, such that it in some way or another can be put into the
model using the same structure.

Thanks


[1]
http://overlays.gentoo.org/proj/alt/browser/trunk/prefix-overlay/profiles/default-prefix

-- 
Fabian Groffen
Gentoo on a different level

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] laying out arch profiles

[Kumba]

Chris Gianelloni wrote:
> On Thu, 2007-07-05 at 18:47 -0400, Mike Frysinger wrote:
>> you proposing we rearchitect it all or just for testing purposes before going 
>> live ?  i can see both ...
> 
> I am proposing rethinking all of it.  My current thoughts run something
> like this:
> 
> arch/amd64
> arch/ppc (not ppc/ppc64 or ppc/ppc32)
> base
> default/linux
> default/freebsd
> default/macos
> kernel/darwin
> kernel/linux
> kernel/freebsd
> release/2007.1
> target/desktop
> target/server
> userland (these aren't all the same type of thing)
> userland/32-bit
> userland/64-bit
> userland/multilib
> userland/freebsd
> userland/hardened
> userland/linux (this could be glibc, instead)
> userland/macos
> userland/no-nptl (not sure we really need this, at all)
> userland/nptl (this either)
> userland/selinux
> userland/uclibc
> 
> Of course, this is just my rough outline.  What you would end up with,
> as a profile, is something like this:
> 
> default/linux/amd64/2007.1/desktop (not much different from now)

I kinda thought up a system like this long ago, but it was more in line with 
node-based profiles.  And wou;d've required gutting the current profile code in 
portage entirely.  The idea being that, you construct the profile up in nodes 
from the top level (much like one does their PATH variable), and the profiles 
would be re-arranged into things like arch/, libc/, kernel/, etc..  In a way, I 
re-organized mips' 2007.1-dev profiles to quasi reflect how we'd look in such a 
layout.

But I like this idea -- it goes halfway towards nodes to some extent (at least 
lines things up for nodes or some other implementation that maybe treats parents 
better).

antarus even had a small draft document up on it that's better in detail:
http://dev.gentoo.org/~antarus/essays/mixin-profiles.txt
(later on, it was decided that there would have to be a pre-defined order for 
the first four nodes: base:arch:kernel:userland, and these first four nodes 
could not repeat.  Everything thereon after was swappable and allowed to be 
placed in any order, such as base:mips:linux:glibc:ip30:o32 (where o32/ip30 can 
be swapped around))

But I definitely see this as a 2008.0 thing at the earliest.  I also see no 
problem with mips joining in on the fun to play with things either!


--Kumba

-- 
Gentoo/MIPS Team Lead

"Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere."  --Elrond
-- 
gentoo-dev@gentoo.org mailing list