Dnia 2014-07-03, o godz. 02:18:23 Joshua Kinard <ku...@gentoo.org> napisał(a):
> [...] > > And so on. The goal was to have profiles/ be extremely flat, with limited > nesting only for categorization purposes. Each component would contain all > of the information specific to that component, and rely on OOP-like > inheritance to override parent-level variables only within that component > (although, <arch> and <kernel> would have to be a little bit more broad in > scope). Another sub-thread, the same question: how do you handle information that needs to be applied to the intersection of the profiles? CHOST for amd64 FreeBSD, for example. > PROFILE also had a set order for the first few pieces, if only to make > parsing and building the profile stack saner for the Portage developers: > PROFILE="base:<KERNEL>:<ARCH>[:<SUBARCH>]:<LIBC>:<EVERYTHING_ELSE>" > > base - Core Gentoo/Portage/whatever information/vars/foobar/kittens I'm against plain 'base' since it quickly becomes a mess. I would prefer having flavor-specific bases, like for example arch/base to mask stuff available only in 1/2 arches and revert it in another arch/. > kernel - Specifies the OS kernel. At the time, only Linux existed, but > I *think* Debian was eyeballing kFreeBSD at the time. So I *think* > I accounted for it back then. What about kernel-ABI intersection? What about Prefix? > arch - Machine arch-specific generic information -- doesn't handle > lower-level things like ISAs/ABIs/Endian, etc. > > subarch - Defines items specific given to given subarch of a main arch. > Items under this directory would carry their parent arch's > name for clarity only. Again, at the time, MIPS would have been > the only real user of this, and, back then, it would've dealt > with SGI-machine-specific packages and USE flags, such as > differentiating an ip32 machine from an ip27 machine or a > cobalt. Now that amd64/x86_64 is considering its own form of > n32 (x32), that would go here, and I imagine arm would > make heavy use of it as well. This is a no-go for multilib support. We need to work on a consistent arch profile tree, not more splitting. > libc - Defines the main C library used. A bit redundant for *BSD, because > they really only have one, but might help if we ever add k*BSD > support (such as freebsd/glibc-based or such). For Linux...could be > tricky, since there are so many libc possibilities there. I feel it > fits better getting defined after <SUBARCH>, especially in the case > of MIPS. I think you need to handle kernel & libc in the same group. > eapi - EAPI didn't exist back when this topic was visited. Basically, > everything was EAPI=0 and there was only Portage (Paludis nor > pkgcore had been invented yet). And what is this supposed to do? > releases - I don't think this existed back then. How it'd operate > nowadays, I have no idea. Probably would contain > version-specific maskings for specific @system packages > to facilitate upgrading, and help us if we ever tried to cut > actual, fixed release points again (like what FreeBSD does > w/ -RELEASE-x.y) I don't think releases would make any sense without heavy intersection with other profiles. -- Best regards, Michał Górny
signature.asc
Description: PGP signature
