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
