[gentoo-user] Profile listings

[gentoo-user] Profile listings

[James]

Hello

Background:
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.



So in /etc/portage/profiles, we have lots of good information. 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. 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?


'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 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.

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?  If the latter, any insight or examples would be keen information.
Yes, I know messing with the 'will of the dev(masters) will put me on a
course of little help; but I just see a better way that I want to experiment
with the profile pieces that are integral to my efforts. My main goal is to
bridge the gap between what is embedded (truly minimalistic)
and a minimized (via the profile) gentoo system.


TIA,
James 

Re: [gentoo-user] Profile listings

[Andreas K. Huettel]

-----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-----

[gentoo-user] Re: Profile listings

[James]

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

Re: [gentoo-user] Profile listings

[Andrew Savchenko]

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

On Sun, 14 Jun 2015 19:22:14 +0000 (UTC) James wrote:
> Hello
> 
> Background:
> 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.
> 
> 
> 
> So in /etc/portage/profiles, we have lots of good information. 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.

Profile do all the stuff that can be done or overridden
in /etc/portage, but they define some sane "default" sets of
settings for common profiles.

USE="-*" will override all USE settings in your profile. As you were
already warned, this may break stuff: e.g. expected
functionality will not be available or package will refuse to build
if it needs at least one of USE flags set (e.g. alternative foo
providers). So you must test things very carefully with USE="-*".

A set of default packages is defined in the "packages" file of each
profile. Profiles usually have "parent" file which lists parent
profiles: they are inherited, but may be overridden here and there
in a child profile. 

If you want an absolutely minimal system, after you have set it up
you may remove some packages even from the @system set. E.g. if
you're sure you don't need man or ssh, remove corresponding
packages. Just be careful here since it is easy to brick your
system here.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-user] Re: Profile listings

[Andreas K. Huettel]

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


> 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. 

Yes it needs some bigger overhaul, there's more or less agreement on it. Unfortunately that is also a big amount of work, and needs a lot of planning. So it won't happen overnight...

That said... Changing profile on your local machine is not a big deal usually. And there just has not been the need for a new profile tree in the meantime. (BTW, before 13 was 10, but that didnt get its name from 2010...)


> 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.

Would be interesting to know what you mean exactly by "minimal" (there is no such profile) and "embedded". 


- -- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0

iQJ8BAEBCgBmBQJVfhByXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0RkJDMzI0NjNBOTIwMDY5MTQ2NkMzNDBF
MTM4NkZEN0VGNEI1Nzc5AAoJEOE4b9fvS1d5NKIQALTtsfL8yWpb1In1CjHVPyv2
LO4UK1sgAwvQc85A1T5fsDTeMsl9lMdA+Em0Onu5+f13AmhSM8/bODQp/2D84eK6
hiOoO+LbWzLZN0vuyoHjAeT8u54iDQmua5ZTHICASyXUNWjOhHWGZJ9z4sNV4bS4
t8HhUdNKvPJEvMXQIJabcypEhSlbGMFnM8ynFPgUzZulkeXd7euVb95An/QK0CK+
3F3t9i6EO1gIgzimKvjZ8kW39OzxevR3DYsvcFrhr43n/H7ZLWYmc03+1334yEmO
zk55YZyE3sau+I8C+FN8+mpw55/YNZ/paHXlKmrsjKw9+ku1733bZ8qdNx1KQu5u
fRuP9EnejMfmS+sNv86cZBOnjqFMByur3TOlbWVVVoXBF43mF4FKmMWRjArb31SM
F6gmJ0rbMdK6mSOr/ahHrbGb/ZEJOBBAs914gE9BdXxF3AobhA24AAPF+rW8hq6L
u2LYbz5S+dnnfuQMRcSkZnRoQtMaNaoE5v+Ze3J9pknelpl2ukvgcIdZjcgfxvkc
U1K567yAHLptRSuug4kGzusEzi5/2N8k95W9GEPRdaWaf3gySiUMaHv1+BFMcHvt
u7ZHPTdPZ/bv5wMqdYTj5JNcFLg+RYi+rdDMKMaCfXzmGK8QfJ8QDEF4WUtyBtcV
zj68mhl3YoP8Cn/8tCo1
=rfDJ
-----END PGP SIGNATURE-----

[gentoo-user] Re: Profile listings

[James]

Andreas K. Huettel <dilfridge <at> gentoo.org> writes:


> > 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.

> Would be interesting to know what you mean exactly by "minimal" (there
> is no such profile) and "embedded". 


Let me state this again, from the top down. Ok Say I install the default
profile, for say and arm64 system (a dev board with graphics chip like
96board.   I can install gentoo on that with a minimum number of packages.
But let's say all I really want is IPtables (or nftables) and ssh.
Surely the default profile has more than is need. So if everything not
absolutely was stripped out, it'd be a minimized gentoo system (my
nomenclature).  This would eventually include a very trimmed kernel,
and very few processes running. I use to build these (some years ago)
and it was easy, just put {USE=-*} in make.conf and add a very few flags.
X86 mostly.


Now say I go to the gentoo_embedded_handbook and build a minimum system
for an arm 7 chip.   It is even small than this aforementioned minimal
gentoo system, as it is embedded (yocto) or OE would be straightforward now,
but Linaro is bloated for an embedded system).  

SO we have this relationship:

embedded << minimal << default as far as I am concerned with profiles.

I undertand the history of gentoo, so I know, particularly below a default
profile, it's been adhoc.  Maybe the minimal should use 'sys-apps/S6' just
for grins?


OK? I not saying this is the current way it is in gentoo, there is no
mapping between and embedded gentoo system and a default gentoo system;
so I am going to develop one, for my interests. Input from others is welcomed.


James

[gentoo-user] Re: Profile listings

[James]

Andrew Savchenko <bircoph <at> gentoo.org> writes:


> Profile do all the stuff that can be done or overridden
> in /etc/portage, but they define some sane "default" sets of
> settings for common profiles.

> USE="-*" will override all USE settings in your profile. As you were
> already warned, this may break stuff: e.g. expected
> functionality will not be available or package will refuse to build
> if it needs at least one of USE flags set (e.g. alternative foo
> providers). So you must test things very carefully with USE="-*".

yes,
of coarse.


> A set of default packages is defined in the "packages" file of each
> profile. Profiles usually have "parent" file which lists parent
> profiles: they are inherited, but may be overridden here and there
> in a child profile. 

Yes.
This is why I was looking for a 'tool' or script that would allow me
to easily browse the default package listings for the different
arch types with a default profile. In fact, I bet I can trim out 
even more packages, or figure what what I need to add back in after
"-*" on a given chipset/arch_family.


> If you want an absolutely minimal system, after you have set it up
> you may remove some packages even from the  <at> system set. E.g. if
> you're sure you don't need man or ssh, remove corresponding
> packages. Just be careful here since it is easy to brick your
> system here.

Yes, I keep old boxes around just to burn a bit and re_install (x86 first).
I bet you have done this before. recently on amd64 or arm64?


> Best regards,
> Andrew Savchenko

TIA,
James

[gentoo-user] Re: Profile listings

[Martin Vaeth]

James <wireless@tampabay.rr.com> wrote:
> This is why I was looking for a 'tool' or script that would allow me
> to easily browse the default package listings for the different
> arch types with a default profile.

If you only want to see the @system set of $PROFILE, use

PORTAGE_PROFILE=/usr/portage/profiles/$PROFILE4 eix -c --system

[gentoo-user] Re: Profile listings

[James]

Martin Vaeth <martin <at> mvath.de> writes:

> 
> James <wireless <at> tampabay.rr.com> wrote:
> > This is why I was looking for a 'tool' or script that would allow me
> > to easily browse the default package listings for the different
> > arch types with a default profile.
> 
> If you only want to see the  <at> system set of $PROFILE, use
> 
> PORTAGE_PROFILE=/usr/portage/profiles/$PROFILE4

This is set in make.conf, right? OK, I'm not familiar with this. Where do I
read up more on "PORTAGE_PROFILE"?

Its not in 'man portage', only briefly mentioned in 'man eix', it's
not in 'man make.conf ??? 

"https://wiki.gentoo.org/wiki//etc/portage/profile/package.provided"
does not match what is on my system. Is there accurate, detailed
info on "PORTAGE_PROFILE"?

http://code.google.com/p/craxyz-gentoo-config/source/browse/trunk/src/gentoo/etc/eixrc?r=8
Is what googling produces on "PORTAGE_PROFILE"


You've stumped me with "PORTAGE_PROFILE"; where do I read more (docs,
scripts, PM sources?



> eix -c --system

Exactly what I was looking for. "-c" is cool; eix never occurred to me.
$42 packages on this amd64 default-profile system.

It there a way to find the current default-profile (system) package listing
for other arches, from my amd64 system? 

But also, 'cat /usr/portage/profiles/default/linux/packages.build' yields 36
packages, ' eix -c --system' yields a list of 42 packages  which matches
'/usr/portage/profiles/base/packages'  with a manual count of course. I just
cannot ferret this out, as different lists of packages are given between 36,
42 36+6 = 42, but where are those other 6 packages?

Here is what is in the list from 'eix -c --system'  {which seems to be
reading (and sorting)/usr/portage/profiles/base/packages}  that is 
not in '/usr/portage/profiles/default/linux/packages.build'

net-misc/iputils
sys-apps/busybox
sys-apps/iproute2
sys-apps/kbd
sys-apps/man-pages
sys-apps/openrc
sys-apps/util-linux
sys-fs/e2fsprogs
sys-process/procps
sys-process/psmisc
virtual/dev-manager
virtual/man
virtual/modutils
virtual/pager
virtual/service-manager

And here is the package list in
'/usr/portage/profiles/default/linux/packages.build' not found in the 'eix
-c --system' listing:

sys-devel/autoconf
sys-devel/automake
sys-devel/libtool
sys-apps/baselayout
sys-apps/makedev
sys-apps/net-tools
sys-devel/bison
sys-devel/flex
sys-devel/gettext
sys-devel/patch
virtual/pkgconfig




Is the differenced due to the files listed in '
/usr/portage/profiles/base/packages' ? It must be more complicated that
that. Any
explanation would be appreciated. Note this was 'manual parsing' so
there could be a mistake or 2, but, what I'm really after is
understanding, if the the portion of which script builds these lists
or how/where/why the lists are set and used.


James




 [1]   default/linux/amd64/13.0 * 

How many packages are required, at a minimum for amd64 and where is the 
exact list obtained from?

[gentoo-user] Re: Profile listings

[James]

Martin Vaeth <martin <at> mvath.de> writes:


> > This is why I was looking for a 'tool' or script that would allow me
> > to easily browse the default package listings for the different
> > arch types with a default profile.

> If you only want to see the  <at> system set of $PROFILE, use

> PORTAGE_PROFILE=/usr/portage/profiles/$PROFILE4 eix -c --system


Ah, you tricked me. You should have written:

'PORTAGE_PROFILE=/usr/portage/profiles/$PROFILE4 eix -c --system'

This returns:     "No matches found." I have this installed:
app-portage/eix=0.30.4 so upgrading to 0.30.10 and testing now.

  I finally found your little file 'defaults.cc' on the net. Neat
little file that "defaults.cc" as I've got to now dig into the
eix sources........

I have this installed:
app-portage/eix=0.30.4 so upgrading to 0.30.10 and testing now.

Still the same result:

# PORTAGE_PROFILE=/usr/portage/profiles/$PROFILE4 eix -c --system
No matches found.


What did I miss?  github?  If I unpack the eix sources, where is defaults.cc ?

<snip>
// vim:set noet cinoptions= sw=4 ts=4:
// This file is part of the eix project and distributed under the
// terms of the GNU General Public License v2.
//
// Copyright (c)
//   Wolfgang Frisch <xororand@users.sourceforge.net>
//   Emil Beinroth <emilbeinroth@gmx.net>
//   Martin Väth <vaeth@mathematik.uni-wuerzburg.de>



curiously,
James

Re: [gentoo-user] Re: Profile listings

[Neil Bothwick]

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

On Tue, 16 Jun 2015 17:42:18 +0000 (UTC), James wrote:

> Ah, you tricked me. You should have written:
> 
> 'PORTAGE_PROFILE=/usr/portage/profiles/$PROFILE4 eix -c --system'

That's what he wrote, but he should have written

PORTAGE_PROFILE=/usr/portage/profiles/$PROFILE eix -c --system

The 4 is an interloper.

> This returns:     "No matches found." I have this installed:
> app-portage/eix=0.30.4 so upgrading to 0.30.10 and testing now.

You did replace $PROFILE with the name of the profile you want to check?
Like this

PORTAGE_PROFILE=/usr/portage/profiles/hardened/linux/amd64/x32 eix -c --system


-- 
Neil Bothwick

... but you can't expect to wield supreme executive power just because some watery tart threw a sword at you!

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[gentoo-user] Re: Profile listings

[Martin Vaeth]

Neil Bothwick <neil@digimed.co.uk> wrote:
>
> PORTAGE_PROFILE=/usr/portage/profiles/$PROFILE eix -c --system
>
> The 4 is an interloper.

Yep, a typo: Next key to the E when one finger presses "shift"...

Although once PORTAGE_PROFILE was supposed to become a
variable in make.conf, it seems to not have made it.
eix still supports it anyway, so that you can change it
"on the fly" without having to change any symlinks.

[gentoo-user] Re: Profile listings

[James]

Neil Bothwick <neil <at> digimed.co.uk> writes:

> You did replace $PROFILE with the name of the profile you want to check?
> Like this
> 
> PORTAGE_PROFILE=/usr/portage/profiles/hardened/linux/amd64/x32 eix -c --system



# PORTAGE_PROFILE=/usr/portage/profiles/default/linux/amd64/13.0/eapi eix -c
--system


worked for the ' [1] default/linux/amd64/13.0 * '

It yields the same (42) packages as just a plain 'eix -c --system' in my
case.

Still good to know.


I'm still having difficulty "casually browsing" the default (minimal?) 
package listing for anything embedded.

# PORTAGE_PROFILE=/usr/portage/profiles/arch/arm/armv7a/eapi eix -c --system

produces the same list of 42 packages?

What did I miss?   I want the default (or minimal) package list for
the various embedded arm profiles: /usr/portage/profiles/arch/arm/ ?

???
Sorry for being so dense....


TIA,
James

[gentoo-user] Re: Profile listings

[Martin Vaeth]

James <wireless@tampabay.rr.com> wrote:
> # PORTAGE_PROFILE=/usr/portage/profiles/arch/arm/armv7a/eapi

This is not a directory. If PORTAGE_PROFILE is not a readable
directory, eix falls back to the symlink

[gentoo-user] Re: Profile listings

[James]

Martin Vaeth <martin <at> mvath.de> writes:


> James <wireless <at> tampabay.rr.com> wrote:
> > # PORTAGE_PROFILE=/usr/portage/profiles/arch/arm/armv7a/eapi

> This is not a directory. If PORTAGE_PROFILE is not a readable
> directory, eix falls back to the symlink

Ok, so I'm running an amd64 default profile system. How do I determine
what the various packages are that will be installed on different
profile system of other architectures?

Surely, I do not have to first install one of those other arch systems,
just to browse the package listing, for a specific profile?


James

[gentoo-user] Re: Profile listings

[Martin Vaeth]

James <wireless@tampabay.rr.com> wrote:
> Martin Vaeth <martin <at> mvath.de> writes:
>
>
>> James <wireless <at> tampabay.rr.com> wrote:
>> > # PORTAGE_PROFILE=/usr/portage/profiles/arch/arm/armv7a/eapi
>
>> This is not a directory. [...]
>
> How do I determine [...]

Choose the directory to which you would put the symlink
(I suppose ..../armv7a in this example).

[gentoo-user] Re: Profile listings

[James]

Martin Vaeth <martin <at> mvath.de> writes:


> >> > # PORTAGE_PROFILE=/usr/portage/profiles/arch/arm/armv7a/eapi

> >> This is not a directory. [...]

> > How do I determine [...]

> Choose the directory to which you would put the symlink
> (I suppose ..../armv7a in this example).




# PORTAGE_PROFILE=/usr/portage/profiles/arch/arm/armv7a eix -c --system
No matches found.


Surely I'm not the first person curious about the default or other 
profile listing of packages for @system on different architectures?

I've tried all sort of command syntax and manually parsed up and down
these directories.

Pick any embedded arm profile and *please* show me the syntax to
determine the @system packages to be installed associate with any
embedded arm profile?

please?

James

[gentoo-user] Re: Profile listings

[Martin Vaeth]

James <wireless@tampabay.rr.com> wrote:
>
> # PORTAGE_PROFILE=/usr/portage/profiles/arch/arm/armv7a eix -c --system
> No matches found.

Obviously, this profile contains no @system packages.
Which appears natural for an embedded profile...

Re: [gentoo-user] Re: Profile listings

[Bruce Schultz]

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

On Fri, Jun 19, 2015 at 4:44 AM, James <wireless@tampabay.rr.com> wrote:

> Martin Vaeth <martin <at> mvath.de> writes:
>
>
> > >> > # PORTAGE_PROFILE=/usr/portage/profiles/arch/arm/armv7a/eapi
>
> > >> This is not a directory. [...]
>
> > > How do I determine [...]
>
> > Choose the directory to which you would put the symlink
> > (I suppose ..../armv7a in this example).
>
>
>
>
> # PORTAGE_PROFILE=/usr/portage/profiles/arch/arm/armv7a eix -c --system
> No matches found.
>
>
> Surely I'm not the first person curious about the default or other
> profile listing of packages for @system on different architectures?
>
> I've tried all sort of command syntax and manually parsed up and down
> these directories.
>
> Pick any embedded arm profile and *please* show me the syntax to
> determine the @system packages to be installed associate with any
> embedded arm profile?
>
> please?
>
> James
>
>
 $ eix -c --system
[I] app-arch/bzip2 (1.0.6-r6{tbz2}@06/28/14): A high-quality data
compressor used extensively by Gentoo Linux
[... lots more lines like this ...]
[I] virtual/shadow (0{tbz2}@06/28/14): Virtual for user account management
utilities
[I] virtual/ssh (0{tbz2}@06/28/14): Virtual for SSH client and server
Found 44 matches.

$ PORTAGE_PROFILE=/usr/portage/profiles/default/linux/arm/13.0/armv7a eix
-c --system
[I] app-arch/bzip2 (1.0.6-r6{tbz2}@06/28/14): A high-quality data
compressor used extensively by Gentoo Linux
[.......]
[I] virtual/shadow (0{tbz2}@06/28/14): Virtual for user account management
utilities
[I] virtual/ssh (0{tbz2}@06/28/14): Virtual for SSH client and server
Found 42 matches.

(this is an almost identical list, but not the 44 vs 42 matches found in
each case)


Note that default/linux/arm/13.0/armv7a profile is building on the
arch/arm/armv7a (what you searched against).

As I understand it, the profiles in arch/arm don't contain any packages
files, so there's no @system packages to list (as you found). I presume
that the arch/arm/... profiles are intended to define compiler flags etc
for cpu variants, and are used as a basis of a more complete profile (such
as default/linux/arm/13.0/armv7a). If you look through
/usr/portage/profiles/profiles.desc, you see the list of all profiles which
would be selectable through 'eselect profile', and I don't find and
arch/... profiles listed in there.

Hope that helps...

Bruce

:b

[-- Attachment #2: Type: text/html, Size: 3176 bytes --]

[gentoo-user] Re: Profile listings

[James]

Martin Vaeth <martin <at> mvath.de> writes:

> 
> James <wireless <at> tampabay.rr.com> wrote:
> >
> > # PORTAGE_PROFILE=/usr/portage/profiles/arch/arm/armv7a eix -c --system
> > No matches found.
> 
> Obviously, this profile contains no  <at> system packages.
> Which appears natural for an embedded profile...

Obviously, one cannot obtain the profiles to other arches from the 
data found in /usr/portage/profile, easily. Surely a front-end would be keen
for this.

Also, I had a friend on an embedded gentoo (arm) board verify  that the same
42 files for @system was installed on his arm board (eix -e --system).


I surely hope that something (gui tool) convenient and robust becomes
available; maybe GLEP64 will help.

For embedded (any arch) I would expect that the @system would not contain
all the files necessary to compile code. After all, that's really what
cross-compiling is all about. I'm not sure a single packages, such as
busybox really contains the best/complete codes that is needed on an
embedded gentoo system, but that is a different issue.


I also think there is room for another profile, between default and embedded
where the target is a single (or focused) build for something like a
sniffer, a data collector, a firewall, a bridge, a router, etc etc
to have less than the "default" profile and specifically matched to
a tuned (aggressively pruned) kernel for a very specific and limited
purpose.  That said, I'm going to think about this a bit more and marinate
over the postings from Andreas and others for a while  longer to decide what
I think it should really be. 


I also think there should be a well defined path of what and how to migrate
from embedded to minimized[focused] and default systems. One could
experiment for example experiment with running a gentoo based
firewall-router on an embedded gentoo system, a minimized[focused] gentoo 
system and a default profile gentoo system all with the same 
firewall-routers codes for cost and security and performance evaluations.



Thanks to all for the excellent information and input! Sorry about being
dense, as now Andreas's posts make more sense, but also highlight the
shortness of breadth of gentoo's current profile system. It's also a 
"pig mess" of code, ideas and old constructs, imho. (note: nothing negative
about the wonderful folks that have maintained and extended profiles over
the years, but, it is time for a discussion and new architecture for the
entire profile landscape, imho. Maybe after Glep 64 is usable it would be
a good time to move forward on profile_modernizations......


Others comments are welcome.


James

[gentoo-user] Re: Profile listings

[James]

Bruce Schultz <brulzki <at> gmail.com> writes:


> Note that default/linux/arm/13.0/armv7a profile is building on the 
> arch/arm/armv7a (what you searched against).


I think all possible profiles for each and every type of gentoo install
should either be readily available on any installed gentoo system, or
on the net or otherwise easy to parse.


> As I understand it, the profiles in arch/arm don't contain any packages
files, so there's no  <at> system packages to list (as you found). I presume
that the arch/arm/... profiles are intended to define compiler flags etc for
cpu variants, and are used as a basis of a more complete profile (such as
default/linux/arm/13.0/armv7a). If you look through
/usr/portage/profiles/profiles.desc, you see the list of all profiles which
would be selectable through 'eselect profile', and I don't find and arch/...
profiles listed in there.


Correct. It's an inconsistent mess, imho. Being able to readily parse
the packages on a given (arch/processor/profile) install would be a keen
tool before making hardware purchases. Embedded to full distro are blurring
the landscape, particularly as arm64 emerges. Also, my cluster build work is
surprisingly revealing that HPC and general prupose clusters are best build
on bare metal or embedded linux systems, particularly but not limited to
performance gains. Gentoo use to "king" in the embedded linux space
and it's an odd (for sure) reality that building clusters, clouds or data
centers on embedded linux is moving forward at a very rapid pace.

I certainly do not wish to alienate or detract from the excellent work our
dev community has achieved. But, embedded (gentoo) linux and cluster/cloud
computing could easily put gentoo on top of the heap again. Surely gentoo is
uniquely positioned to build clusters that are not on top of 'bloatware'!

> Hope that helps...
> Bruce

YES, and I appreciated every comment!


later,
James

Re: [gentoo-user] Re: Profile listings

[Neil Bothwick]

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

On Fri, 19 Jun 2015 19:56:53 +0000 (UTC), James wrote:

> > Note that default/linux/arm/13.0/armv7a profile is building on the 
> > arch/arm/armv7a (what you searched against).  
> 
> I think all possible profiles for each and every type of gentoo install
> should either be readily available on any installed gentoo system, or
> on the net or otherwise easy to parse.

They already are, profiles are part of the portage tree. For example, on
this amd64 box

% PORTAGE_PROFILE=/var/portage/profiles/default/linux/arm/13.0/armv7a eix -c --system
[snip]
Found 42 matches.

The nil return before was caused by search in one of the arch
directories, which are not complete profiles but data to be used by
profiles. It is a little confusing, but if you stick to profiles under
default/linux you should get useful information.


-- 
Neil Bothwick

0 and 1. Now what could be so hard about that?

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[gentoo-user] Re: Profile listings

[James]

Neil Bothwick <neil <at> digimed.co.uk> writes:


> > I think all possible profiles for each and every type of gentoo install
> > should either be readily available on any installed gentoo system, or
> > on theet or otherwise easy to parse.

> They already are, profiles are part of the portage tree. For example, on
> this amd64 box
> 
> % PORTAGE_PROFILE=/var/portage/profiles/default/linux/arm/13.0/armv7a eix
-c --system

> Found 42 matches.

I get that all the defaults, regardless of arch, have the same 42 list
of packages (at least what I have checked), even default for the arm
variants which are usually thought of as embedded. I get what Andreas
wrote finally where inheritance picks up other packages.


> The nil return before was caused by search in one of the arch
> directories, which are not complete profiles but data to be used by
> profiles. It is a little confusing, but if you stick to profiles under
> default/linux you should get useful information.

/usr/portage/profiles/embedded/packages shows:
*>=sys-apps/busybox-0.60.5-r1

I guess that busybox is the only package that all (gentoo) embedded profiles
require. Granted I have not looked at all the variants of profile, including
embedded for the different arches found in gentoo.


I just think there should be a cleaner and quicker way to see these lists,
and I think there should be a 'standard way' to migrate between embedded
and default, for each and every arch variant. It's not been a clean nor easy
thing to ferret out, imho. Little documentation. I do appreciate your
efforts and the information provided by the others too. I think in the
new world of clusters running on  bare metal to full, bloated distros,
gentoo should have a way to move between profiles, is a good idea. YMMV.
Granted workstations might not want to be part of this changing of profiles,
but for servers and focused, single purpose machines, moving from profile to
profile, should not be that big of a deal. This is all a work in progress
for me. The more I learn about clusters, the more it radically
changes what I have seen in the past of embedded systems and *nix systems.


Last, I'd just like share another insight. Clusters build on minimal or
embedded systems will be far easier to secure, because there's just less
to monitor for unauthorized changes. The biggest issue with Clusters and
Clouds, that nobody  big talks about, are the rampant security problem therein.


Thanks,
James

[gentoo-user] Re: Profile listings

[Jonathan Callen]

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

On 2015-06-19 15:46, James wrote:
> Martin Vaeth <martin <at> mvath.de> writes:
> 
>> 
>> James <wireless <at> tampabay.rr.com> wrote:
>>> 
>>> # PORTAGE_PROFILE=/usr/portage/profiles/arch/arm/armv7a eix -c
>>> --system No matches found.
>> 
>> Obviously, this profile contains no  <at> system packages. Which
>> appears natural for an embedded profile...
> 
> Obviously, one cannot obtain the profiles to other arches from the
>  data found in /usr/portage/profile, easily. Surely a front-end
> would be keen for this.
> 
> Also, I had a friend on an embedded gentoo (arm) board verify  that
> the same 42 files for @system was installed on his arm board (eix
> -e --system).
> 
> 
> I surely hope that something (gui tool) convenient and robust
> becomes available; maybe GLEP64 will help.
> 
> For embedded (any arch) I would expect that the @system would not
> contain all the files necessary to compile code. After all, that's
> really what cross-compiling is all about. I'm not sure a single
> packages, such as busybox really contains the best/complete codes
> that is needed on an embedded gentoo system, but that is a
> different issue.
> 
> 
> I also think there is room for another profile, between default and
> embedded where the target is a single (or focused) build for
> something like a sniffer, a data collector, a firewall, a bridge, a
> router, etc etc to have less than the "default" profile and
> specifically matched to a tuned (aggressively pruned) kernel for a
> very specific and limited purpose.  That said, I'm going to think
> about this a bit more and marinate over the postings from Andreas
> and others for a while  longer to decide what I think it should
> really be.
> 
> 
> I also think there should be a well defined path of what and how to
> migrate from embedded to minimized[focused] and default systems.
> One could experiment for example experiment with running a gentoo
> based firewall-router on an embedded gentoo system, a
> minimized[focused] gentoo system and a default profile gentoo
> system all with the same firewall-routers codes for cost and
> security and performance evaluations.
> 
> 
> 
> Thanks to all for the excellent information and input! Sorry about
> being dense, as now Andreas's posts make more sense, but also
> highlight the shortness of breadth of gentoo's current profile
> system. It's also a "pig mess" of code, ideas and old constructs,
> imho. (note: nothing negative about the wonderful folks that have
> maintained and extended profiles over the years, but, it is time
> for a discussion and new architecture for the entire profile
> landscape, imho. Maybe after Glep 64 is usable it would be a good
> time to move forward on profile_modernizations......
> 
> 
> Others comments are welcome.
> 
> 
> James
> 

The list of all profiles that can be chosen (for all architectures)
can be found in ${PORTDIR}/profiles/profiles.desc .  There are other
"profile-like" directories under ${PORTDIR}/profiles, but these are
only used as parents for a "complete" profile, as would be listed in
profiles.desc.  Most profiles do not change much, if anything, in the
@system set.  The @system set contains much more than you would
probably need for a dedicated, embedded device.

- -- 
Jonathan Callen

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJVhi96AAoJEEIQbvYRB3mggLMP/3xi0EQFcHXx1rrPufYq/is4
VVne2H9PtvFtfhqCVpjqIMFqknL0XwtjDRJx/EdFO1Ym02tR5OX/iU4hcmyRVg9X
6OgecksDhtQVs4UVfNkjBOEbMUMMFKEimboLq1w9j8RwmjMx84ZYuhkNag33d72X
4St4ly8Y7w1feeirn925of7Dj7upQeievpDs6kK7WtLIA8t8nZeBmNFUfkjlAfCe
YSukUBqzK8vq92M5jmJRbtPaOePZppJBRcmiPOqqF8uhtXozo9dgoOk1TANXtNEV
fip4NLczVM8eOf54JLAM6ttBuBK1yTQx4csnPBbd6WU3vD2E0YSuZjFADFBWsTiY
8Q7ZvZIg7i60ZwzQ127MTgOQQDYHEgpEorWC9X1EKHMIke6k9mFQtdaGMPIkb8jt
3F/LbV4YP6h0Q6QQdQq4LpWBmvZ78LmJwm5KtXMZean4Z5G3rSzmbu/nsSJy0zEW
zJu2vKcitzzJNE7c0CBpWVUcUj9ZB819ao5tMxbft/LJNTgURz7wScW1FSS6R+n1
EzQgBQdWyIXaYMqAAapYrMgZhKdij4NAGp7rUi+uIIrxleu5ECh9a6/VfVr9Z7V8
v+uLYuiBX5agFvjA7UCy5gq/6vD/QmlWlh88lMpp0dBLTN/ovM3CcBH5h0rOBHxf
Z7gzy0i/uEhZoo235pJc
=9peY
-----END PGP SIGNATURE-----

[gentoo-user] Re: Profile listings

[James]

Neil Bothwick <neil <at> digimed.co.uk> writes:


> % PORTAGE_PROFILE=/var/portage/profiles/default/linux/arm/13.0/armv7a eix
-c --system
> [snip]
> Found 42 matches.
> 
> The nil return before was caused by search in one of the arch
> directories, which are not complete profiles but data to be used by
> profiles. It is a little confusing, but if you stick to profiles under
> default/linux you should get useful information.


Interestingly, you used "var" instead of "usr". From earlier, Martin used

"PORTAGE_PROFILE=/usr/portage/profiles/$PROFILE eix -c --system"


Granted "$PROFILE" needed expansion, but he put "/usr" and now
you have it working with "/var" at the head of the path-string.

Interestingly enough, "/var/portage" is not even a dir, yet the 
path-string you used does work.

' PORTAGE_PROFILE=/var/portage/profiles/default/linux/arm/13.0/armv7a eix -c
--system'

Which does work nicely.....


Care to explain? 


James

[gentoo-user] Re: Profile listings

[James]

Jonathan Callen <jcallen <at> gentoo.org> writes:


> The list of all profiles that can be chosen (for all architectures)
> can be found in ${PORTDIR}/profiles/profiles.desc .  There are other
> "profile-like" directories under ${PORTDIR}/profiles, but these are
> only used as parents for a "complete" profile, as would be listed in
> profiles.desc.  Most profiles do not change much, if anything, in the
>  <at> system set.  The  <at> system set contains much more than you would
> probably need for a dedicated, embedded device.


OK.

So I want to build and embedded gentoo system on an amd64:

model name	: AMD FX(tm)-8350 Eight-Core Processor  

What this the embedded profile? (show me the syntax for this?).


I only need busybox (looking at the other embedded profiles). If I choose to
install iptables, as the only package, after busybox, the dependancy-tree
will pull in what else I need. Then just mod the kernel and I have embedded
gentoo on an amd64 system with iptables.  

This will work, right? Isn't this what you are implying, or is the
profile system incomplete?



James

Re: [gentoo-user] Re: Profile listings

[Neil Bothwick]

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

On Sun, 21 Jun 2015 16:09:53 +0000 (UTC), James wrote:

> Interestingly, you used "var" instead of "usr". From earlier, Martin
> used
> 
> "PORTAGE_PROFILE=/usr/portage/profiles/$PROFILE eix -c --system"

I have PORTDIR at /var/portage.


-- 
Neil Bothwick

Experience is directly proportional to the value of equipment destroyed.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-user] Re: Profile listings

[Alan McKinnon]

On 21/06/2015 19:49, Neil Bothwick wrote:
> On Sun, 21 Jun 2015 16:09:53 +0000 (UTC), James wrote:
> 
>> Interestingly, you used "var" instead of "usr". From earlier, Martin
>> used
>>
>> "PORTAGE_PROFILE=/usr/portage/profiles/$PROFILE eix -c --system"
> 
> I have PORTDIR at /var/portage.
> 
> 


portage for a long long time went in /usr/portage because that's where
FreeBSD put it, and drobbins was mightily enthralled by FreeBSD.

But it's a stupid place for it to go on Linux and most of the sane
technical Gentoo world agrees it really is a better fit in /var/portage.
However, due to a highly unlikely confluence of the phases of the moon
and an oddly-painted bikeshed (aquamarine with ochre polka dots), no-one
seems to have ever gotten around to actually fixing it once and for all
everywhere.

Bottom line: folks will see both in real life.
Procedure: If you have the one, and see the other, then just change the
top-level dir in what you see.

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: Profile listings

[Peter Humphrey]

On Sunday 21 Jun 2015 22:02:02 Alan McKinnon wrote:
> portage for a long long time went in /usr/portage because that's where
> FreeBSD put it, and drobbins was mightily enthralled by FreeBSD.
> 
> But it's a stupid place for it to go on Linux and most of the sane
> technical Gentoo world agrees it really is a better fit in /var/portage.
> However, due to a highly unlikely confluence of the phases of the moon
> and an oddly-painted bikeshed (aquamarine with ochre polka dots), no-one
> seems to have ever gotten around to actually fixing it once and for all
> everywhere.
> 
> Bottom line: folks will see both in real life.
> Procedure: If you have the one, and see the other, then just change the
> top-level dir in what you see.

Or, as I do, put it in its own partition and you can mount it wherever you 
like. Just point make.conf and repos.conf/gentoo.conf at it.

Actually, using LVM on RAID-1 I have portage, packages and distfiles all in 
their own partitions; just three of 15 under /dev/vg7.

-- 
Rgds
Peter

[gentoo-user] Re: Profile listings

[James]

Peter Humphrey <peter <at> prh.myzen.co.uk> writes:

> 
> On Sunday 21 Jun 2015 22:02:02 Alan McKinnon wrote:
> > portage for a long long time went in /usr/portage because that's where
> > FreeBSD put it, and drobbins was mightily enthralled by FreeBSD.
There is no dir '/var/portage' on my system. Yet this command works fine:

"PORTAGE_PROFILE=/var/portage/profiles/default/linux/arm/13.0/armv7a eix -c
--system "

Strange, to say the least.



> > But it's a stupid place for it to go on Linux and most of the sane
> > technical Gentoo world agrees it really is a better fit in /var/portage.
> > However, due to a highly unlikely confluence of the phases of the moon
> > and an oddly-painted bikeshed (aquamarine with ochre polka dots), no-one
> > seems to have ever gotten around to actually fixing it once and for all
> > everywhere.

"pig-mess" like I said earlier.



> > Bottom line: folks will see both in real life.
> > Procedure: If you have the one, and see the other, then just change the
> > top-level dir in what you see.
> 
> Or, as I do, put it in its own partition and you can mount it wherever 
> you like. Just point make.conf and repos.conf/gentoo.conf at it.


Yea, yea, I can make a custom mess too: aka brilliantly (in my own mind)
organize it, I mean.


The bottom line for me is:

1) folks should be able to migrated up and down the profile tree. It's give
us some neat abilities. If I have a workstation that becomes old, I could
change the profile and move it'down' to default or embedded and turn it
into a decicated, minimized router, firewall, bridge, sniffer etc etc. I
think the offcial word is changing profiles is not recommended.

2) Some thing of a profile needs to exist between an embedded system
(busybox only) and the default.

3) I'm looking forward to a gentoo-standard where systems can be fully
audited to account for each and every file. Sure you can do this now, if you
plann and do lots of things from the beginning as well as with every
install. Maybe Glep64 will be the catalyst for system tools to support this
(security) feature.

4) most importantly: my cluster research and experiences have yielded a
startling and wonderful epiphany. That is Clusters/clouds/<distributed
whatever> runs fastest and most reliably on bare metal. Embedded Gentoo is
my pathway to direct and easy access to bare metal clusters. Cleaning up the
profiles just seems logical to me, after noodling around with in the
profiles......  

5) Also, security in the cluster/cloud world is almost impossible building
clusters on top of 'bloated OSes and bloated system packages'. YMMV.
Containers nor VM is going to keep clusters/clouds secure; and those sort of
herculean efforts, currently underway, are akin to patching a 200 year old,
worm infested, wooden ship, whilst rounding Cape Horn.....

It's actually hilarious to watch  and listen to these fools......  The NSA
is probably clandestinely cloud funding all these cloud vendors.....
(ah ha ha ha ha ha) !


Thanks to all for the education. 
HI_ho HI_ho 
 a profiling we go
 HI_ho HI_ho,


James

[gentoo-user] Re: Profile listings

[Martin Vaeth]

James <wireless@tampabay.rr.com> wrote:
> There is no dir '/var/portage' on my system. Yet this command works fine:
>
> "PORTAGE_PROFILE=/var/portage/profiles/default/linux/arm/13.0/armv7a eix -c
> --system "
>
> Strange, to say the least.

Not at all strange: Again, PORTAGE_PROFILE points to a non-directory,
so it is ignored, and the default is chosen.

>> > But it's a stupid place for it to go on Linux and most of the sane
>> > technical Gentoo world agrees it really is a better fit in /var/portage.
>
> "pig-mess" like I said earlier.

A default is a default. It is you - the sytem adminstrator - who is
responsible to determine the setting most appropriate for his system.
For instance, when exporting, a sane place might be
/srv/gentoo-repo

>> Or, as I do, put it in its own partition and you can mount it wherever 
>> you like. Just point make.conf and repos.conf/gentoo.conf at it.
>
> Yea, yea, I can make a custom mess too: aka brilliantly (in my own mind)
> organize it, I mean.

That's what you are supposed to do with a meta-distribution,
especially if you do not like the default choice.

> The bottom line for me is:
>
> 1) folks should be able to migrated up and down the profile tree. It's give
> us some neat abilities. If I have a workstation that becomes old, I could
> change the profile and move it'down' to default or embedded and turn it
> into a decicated, minimized router, firewall, bridge, sniffer etc etc. I
> think the offcial word is changing profiles is not recommended.

If you don't know what you are doing, you keep the pieces:
Some conversion (e.g. non-multilib->multilib or 32bit->64bit)
are really hard. It won't help you just to change the profile:
You would need cross-compilation etc.

OTOH, if you just want to transform a desktop into a server (e.g.)
it is very simple: Mainly this has nothing to do with the profile
but with the USE-flags and packages which you select manually.

> 2) Some thing of a profile needs to exist between an embedded system
> (busybox only) and the default.

No. If you are running an embedded system, you are supposed to be
expert enough to make your own profile. If you lack the experience
to do it, don't do it, since otherwise you will just end up with a
mess anyway. Use instead one of the save profiles and do not try to
shrink it beyond sanity, so that things work and do not break
unexpectedly.

> Cleaning up the profiles just seems logical to me, after noodling
> around with in the profiles......

Fine. If you are an expert enough do it. You will have then the
experience that nobody else will have exactly your need and thus
understand that having a profile only for your need in the main
gentoo repository would be pointless. And of course, you are then
expert enough to create a custom profile (or build one modifying
an exising one) without asking here.
If you are not such an expert: See above: Use one of the save profiles
and do not try to shrink it beyond sanity, so that things work and do
not break unexpectedly.


> 5) Also, security in the cluster/cloud world is almost impossible building
> clusters on top of 'bloated OSes and bloated system packages'. YMMV.

None of the gentoo profiles is bloated (systemd excluded, of course).
And even if a package is installed which you do not need, it will not
make your system insecure if it is not used. Your configuration and
USE-flags are much more important than the tiny list of @system packeges:
Shrinking these even more is really only a task for the experienced expert.