From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 27B65138CEE for ; Sat, 20 Jun 2015 02:52:19 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 321671401B; Sat, 20 Jun 2015 02:52:07 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 126E0E07D5 for ; Sat, 20 Jun 2015 02:52:05 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Z68t0-0003Mv-Rq for gentoo-user@lists.gentoo.org; Sat, 20 Jun 2015 04:52:03 +0200 Received: from rrcs-71-40-157-251.se.biz.rr.com ([71.40.157.251]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 20 Jun 2015 04:52:02 +0200 Received: from wireless by rrcs-71-40-157-251.se.biz.rr.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 20 Jun 2015 04:52:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-user@lists.gentoo.org From: James Subject: [gentoo-user] Re: Profile listings Date: Sat, 20 Jun 2015 02:51:55 +0000 (UTC) Message-ID: References: <20150615021218.442abc3967649188f0233b94@gentoo.org> <20150616212651.755ff446@digimed.co.uk> <20150619213821.65c92f0e@digimed.co.uk> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 71.40.157.251 (Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Firefox/36.0 SeaMonkey/2.33.1) X-Archives-Salt: 0871d96d-ded5-438c-98e6-c006e2fd941e X-Archives-Hash: 11264aca235e266f3a610392943bd9bc Neil Bothwick 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