From: James <wireless@tampabay.rr.com>
To: gentoo-user@lists.gentoo.org
Subject: [gentoo-user] Re: Profile listings
Date: Sun, 14 Jun 2015 22:21:41 +0000 (UTC) [thread overview]
Message-ID: <loom.20150615T002043-497@post.gmane.org> (raw)
In-Reply-To: 201506142240.41496.dilfridge@gentoo.org
Andreas K. Huettel <dilfridge <at> gentoo.org> writes:
> You're venturing into wonderland. Expect some mad hatters to pop up.
Yes!
> > 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.
It use to work. So maybe building up from an embedded profile for a given
arch? Problem is I'm not certain there is an "embedded" profile
for any of the arches? If there is, then I could use that list of
packages and tweak the list for another arch.
> > 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.
OK. Good info. adhoc, as I suspected, burried in codes, scrips
and data structures..... Busybox was the only common package
I could find for embedded trees.
> The choices from eselect come from /usr/portage/profiles/profiles.desc
Ah!
> 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.
Ahhh! Boy some organizing tool would be keen to discern the differences.
The next part would be the buzilla status of the profiles in comparison
to what is common. Remember, I'm looking bottom (minimalistic upwards)
to it should be much less that the (77) baseline packages....
There is a gap between embedded and baseline(=default); and no rhyme or
reason. Adhoc per arch, mostly, if at all.
> > The next thought is how then to best (succinctly) determine the complete
> > list of packages that will be pulled into any given (arch) profile.
>
> 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.
Yep! I keep old boxes around for such (destructive risk) noodling.
> > 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.
Surely I know this. But looking for some standardization for
"embedded-Gentoo" (i.e. the most mini-sizable possible embedded gentoo
linux) should
not be that difficult for most common arches we support. Getting from there
to "minimized" and then "default" from the same arch tree (pathways) should
be mostly the same except for things mandated by the functional differences
of the arches themselves. I think I'm going to limit this (for now) to these
arches (AMD64 x86_32 arm64 arm(32).
> For an example, check my dev overlay (it adds one profile for x86 and for
> amd64).
Will do.
> 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
That is the 'top down' approach ((default --> embedded). You'd think this
quest is the same, but I'm going to first look at this 'bottom up' (embedded
--> minimal --> default); but much is missing. So I'll look at what exists
in various embedded arches. I just cannot reconcile why there is no bridge
between embedded and (some/any)minimal and default.
I do understand now why you cannot (usually) change profiles; the profile
system is a mess and really needs a whole new overall design. That's why we
still have '13' in the profiles even though it's 2015. The entire gentoo
profile system is showing it's age and evolutionary problems, imho. I not
saying I'm taking on that brood of hornets, but just a few select
migrations from embedded to minimal.
Note {embedded << minimal << default} I still have some vintage gentoo
systems running which have very few flags set and include (USE="-*") in
make.conf. And a {state-machine/executive/rtos << embedded(linux)},
just so we are on the same page.
thx!
James
next prev parent reply other threads:[~2015-06-14 22:21 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-14 19:22 [gentoo-user] Profile listings James
2015-06-14 20:40 ` Andreas K. Huettel
2015-06-14 22:21 ` James [this message]
2015-06-14 23:38 ` [gentoo-user] " Andreas K. Huettel
2015-06-15 4:27 ` James
2015-06-14 23:12 ` [gentoo-user] " Andrew Savchenko
2015-06-15 4:37 ` [gentoo-user] " James
2015-06-15 12:15 ` Martin Vaeth
2015-06-15 15:25 ` James
2015-06-16 17:42 ` James
2015-06-16 20:26 ` Neil Bothwick
2015-06-17 8:18 ` Martin Vaeth
2015-06-17 16:11 ` James
2015-06-18 7:05 ` Martin Vaeth
2015-06-18 15:21 ` James
2015-06-18 17:33 ` Martin Vaeth
2015-06-18 18:44 ` James
2015-06-18 19:59 ` Martin Vaeth
2015-06-19 19:46 ` James
2015-06-21 3:29 ` Jonathan Callen
2015-06-21 16:17 ` James
2015-06-19 2:27 ` Bruce Schultz
2015-06-19 19:56 ` James
2015-06-19 20:38 ` Neil Bothwick
2015-06-20 2:51 ` James
2015-06-21 16:09 ` James
2015-06-21 17:49 ` Neil Bothwick
2015-06-21 20:02 ` Alan McKinnon
2015-06-21 23:53 ` Peter Humphrey
2015-06-22 13:38 ` James
2015-06-22 14:47 ` Martin Vaeth
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=loom.20150615T002043-497@post.gmane.org \
--to=wireless@tampabay.rr.com \
--cc=gentoo-user@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