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