Re: [gentoo-user] Profile listings

["Andreas K. Huettel" <dilfridge@gentoo.org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi James ,

> As a minimalist I'm trying to ferret out the differences in some of the
> more minimal profiles versus potential embedded profiles, across several
> different architectures: (arm32, arm64 x63_32 x86_64 ppc etc). I am also
> quite curious to find a tool that will clearly list the complete set of
> packages a given (eselected) profile will yield and the best ways to
> customize that list of minimal (critical) packages.

You're venturing into wonderland. Expect some mad hatters to pop up. 

> So in /etc/portage/profiles, we have lots of good information. 

You probably mean /usr/portage/profiles?

> For example
> the 'base' dir currently lists 77 packages found in most profiles (?). The
> '/usr/portage/profiles/arch.list' dir lists not only the recognized arches
> but  also "Prefix Keywords". I'm not exactly sure how all of this profile
> stuff works; who decides what's (packages) in and out, package_masks etc
> etc.

> So my questions related to how does gentoo actually determines the exact
> list of programs that are minimally installed, with the specific
> arch and the profile selected? In previous times, I just put USE='-*' in
> the make.conf file and built upwards from there. 

Don't, it breaks things.

> Still there were baseline
> packages in the most minimal of stage based gentoo builds. I'm looking for
> a current approach to bridging between a baseline default profile (for
> amd64 that would be: [1]   default/linux/amd64/13.0 *) and  an embedded
> amd64 profile (if one currently exist? How do I find the potential
> profiles for say another arch (ppc for example), from an amd64 based
> gentoo system? Tools? Recommended scripts to review?

Your best bet is the (undocumented) portage python API. I guess the question 
is specific enough that you can pop into #gentoo-portage and ask. 

> 'eselect profile list' currently shows 21  amd64 choices:
> 
>  [1]   default/linux/amd64/13.0 *
>   [2]   default/linux/amd64/13.0/selinux
>   [3]   default/linux/amd64/13.0/desktop
>   [4]   default/linux/amd64/13.0/desktop/gnome
>   [5]   default/linux/amd64/13.0/desktop/gnome/systemd
>   [6]   default/linux/amd64/13.0/desktop/kde
>   [7]   default/linux/amd64/13.0/desktop/kde/systemd
>   [8]   default/linux/amd64/13.0/desktop/plasma
>   [9]   default/linux/amd64/13.0/desktop/plasma/systemd
>   [10]  default/linux/amd64/13.0/developer
>   [11]  default/linux/amd64/13.0/no-multilib
>   [12]  default/linux/amd64/13.0/systemd
>   [13]  default/linux/amd64/13.0/x32
>   [14]  hardened/linux/amd64
>   [15]  hardened/linux/amd64/selinux
>   [16]  hardened/linux/amd64/no-multilib
>   [17]  hardened/linux/amd64/no-multilib/selinux
>   [18]  hardened/linux/amd64/x32
>   [19]  hardened/linux/musl/amd64
>   [20]  default/linux/uclibc/amd64
>   [21]  hardened/linux/uclibc/amd64
> 
> 
> 
> But looking here at the files and directories ( ls /usr/portage/profiles)
> 
> I see an organization structure that differs from the profile listing
> semantics. So is there a  script(s)  that shows me what is being read from
> the directory tree that yields those 21 choices? It seems a bit convoluted
> to me, but I could easily have missed the documents that organize and
> discuss such details? Or at least a listing of the scripts that build these
> profile lists? Or is this adhoc?

The choices from eselect come from /usr/portage/profiles/profiles.desc

About what each of these profiles does - you can find that out by starting 
with the directory given in profiles.desc (e.g., 
/usr/portage/profiles/hardened/linux/amd64 for choice [14]) and follow the 
content of the "parent" files in the directories for inheritance. 

> The next thought is how then to best (succinctly) determine the complete
> list of packages that will be pulled into any given (arch) profile. Is this
> a fiefdom situation where those devs that maintain that arch (tongue in
> cheek) quasi-use these scripts, config files and the /usr/portage/profiles
> tree structure, consistently or as they wish? I'm not looking for emotional
> responses, just clarity on where we are.

Basically you have to follow the inheritance tree as defined by the parent 
files, and add stuff up. For the detailed algorithms, see app-doc/pms (good 
bedtime reading).

The targets (systemd, desktop, kde, gnome) are more or less maintained by the 
respective teams. 

The arch dirs are maintained by the arch teams. 

Since changes to any of these dirs may affect a lot, they are usually done 
with care and rather minimally. 

> Finally. What if I want to "roll my own profiles"; should I just build on
> one of the minimal ones or create something anew that exists only on my
> systems?  

You *can* roll your own profiles, but it's non-trivial and can cause pain. 
You'll probably end up asking a lot of questions before it works. It took me a 
while to figure it out even when already knowing how the main profile tree 
more or less works. 

For an example, check my dev overlay (it adds one profile for x86 and for 
amd64).

Your safest bet would be to inherit the arch main profile (e.g. 
default/linux/amd64/13.0) and maybe remove some stuff. However, there's not 
too much to remove left there. So I'm not sure if it's really worth the 
effort. 

Cheers, Andreas

- -- 
Andreas K. Huettel
Gentoo Linux developer (council, perl, libreoffice)
dilfridge@gentoo.org
http://www.akhuettel.de/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJVfebGAAoJEB9VdM6hupKVj88P/RZ5WB3y0LJSVt+bffjawAHb
dGENbzGx0MCqlr+yAlxkzbY8fVfpS0w9j4+p2/rWeqVv1VZLxqA0SOWKUD9wZ61W
ScxLMq9Xe7juBwmOdNE+83QVRSNJUlPP4spBDhDf89qLlYVEgNCaOo/8nbWaQzjM
JR7e6Jjhf/QI/2ySkYybRhXVAatw+u9E++VsucBY17+qq/gIES2U3Rnuajq6OSFR
acv2lrVYA6MujX/5dWqypDLVE2xuuUgr1SHn+BWdOReI4ON7kMrrlkxa1W+/AUxm
2ByZc0LF3Xtdsxrnbd0wJuqdp0j4Fk3WX7VOU1appqt4bAG0GkXfwTUt0XVn7Wa9
0fJAlo/LYURie/xBRh4E0pNUys0///r8iR9d0ikXQmL1/UjC1OzHTNW1s5K3P1o8
1/3urkIMUQz2iFOJ29Rx6Iwn3862yYEkb2fn3CHGO6T/6rc8KiwjKT+mybCVn5lv
qp4AWzXwOm8jILYrqdYcwwhoDKtaHylJM2iVCVTI0wKf/BOor/I/QyyPXryZP0Jm
yNn3ybaHQX2V++PNH6DZK1l71BTmyJcvau7Jl8lQZ9EVZNoAheMyfng8rzKduulE
tIQ300wZJOXqqRyRpG22TMEuGG0EkV8d3fdP0I596nW7QyzPhRcjyQGMNOWFioZl
g5xt/rezdqCDhvd6saFx
=VlVg
-----END PGP SIGNATURE-----