From: Chris Gianelloni <wolf31o2@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] laying out arch profiles
Date: Mon, 09 Jul 2007 11:47:45 -0700 [thread overview]
Message-ID: <1184006865.8412.20.camel@inertia.twi-31o2.org> (raw)
In-Reply-To: <200707051847.41606.vapier@gentoo.org>
[-- 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 --]
next prev parent reply other threads:[~2007-07-09 18:51 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-27 16:31 [gentoo-dev] laying out arch profiles Mike Frysinger
2007-07-05 21:18 ` Chris Gianelloni
2007-07-05 22:47 ` Mike Frysinger
2007-07-06 8:15 ` [gentoo-dev] " Steve Long
2007-07-06 15:16 ` Mike Frysinger
2007-07-09 18:47 ` Chris Gianelloni [this message]
2007-07-09 19:04 ` [gentoo-dev] " Fabian Groffen
2007-07-15 8:28 ` Kumba
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1184006865.8412.20.camel@inertia.twi-31o2.org \
--to=wolf31o2@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox