On Sun, Jun 21, 2009 at 04:55:02PM +0200, Sebastian Pipping wrote: > Robin H. Johnson wrote: > > Relevant to this, I might not want to disclose my profile inheritance > > tree. Here's one of them for you: > > /etc/make.profile > > /etc/managed-portage/hosts/build_webdb/make.profile > > /etc/managed-portage/common/post/make.profile > > /etc/managed-portage/class/webdb/make.profile > > /etc/managed-portage/class/db/make.profile > > /etc/managed-portage/class/web/make.profile > > /etc/managed-portage/common/pre/make.profile > > /etc/managed-portage/location/surrey/make.profile > > /etc/managed-portage/hwtype/nehalem/make.profile > > /usr/portage/profiles/default/linux/amd64/2008.0 > Which of these is the target of the /etc/make.profile link? > The last one? My current approach resolves the soft link and > cuts of the profiles dir prefix. So in case it's the last for > you that would be
$MP = /etc/managed-portage. There is a symlink right now, but there might not be in future. /etc/make.profile/parents -> $MP/hosts/build_webdb/make.profile $MP/hosts/build_webdb/make.profile/parents: $MP/common/pre/make.profile $MP/location/surrey/make.profile $MP/class/webdb/make.profile $MP/hwtype/nehalem/make.profile $MP/common/post/make.profile $MP/class/webdb/make.profile/parents: $MP/class/db/make.profile $MP/class/web/make.profile $MP/hwtype/nehalem/make.profile/parents: /usr/portage/profiles/default/linux/amd64/2008.0 The following have no parents: $MP/class/db/make.profile $MP/class/web/make.profile $MP/common/pre/make.profile $MP/common/post/make.profile $MP/location/surrey/make.profile > To auto-filter profiles would parsing profiles.desc work? > Would a synced CVS checkout of > <http://sources.gentoo.org/viewcvs.py/gentoo-x86/profiles/> > give anything more that I could or should use? I'm wondering how profiles should be reported. Rather than just the endpoint, I'm thinking that we should resolve them and generate a list, like the above, then explicitly whiteout the non-public ones. So in the above, you'd report: === (censored) X 13 default/linux/amd64/2008.0 === The resolving can be terminated at each profile that is listed in profiles.desc, so you can just report default/linux/amd64/2008.0 and not all the profiles that make that up. > I see. How about this approach instead: > - Get list of overlays from layman-global.txt, through either > A) Download and keep a snapshot of layman-global.txt in sync ourselves Just A, per your other email. > - Take the official tree and globa overlays (overlays from > layman-global.txt) into account for statistics > > - Resolve ${storage} from /etc/layman/layman.cfg > > - Include ebuilds from ${storage}/{global,overlays,here} and > /usr/portage/ > > What it does not catch is people putting their own ebuilds > right into the main tree. As they lose them all on the next sync > are we safe to assume that no one really does that? > If not are there alternatives to comparing to a synced checkout > of gentoo-x86 (either rsync or CVS)? Why does the raw content of the trees matter? I can see the source (which tree) of a given package that is already installed mattering, but not the raw content of the tree. > Any concerns or ideas for improvement? /usr/portage might NOT be from the public rsync. - Many devs have it straight from CVS. - Infra has it stripped of a lot of GUI packages (like gnome, kde etc). -- Robin Hugh Johnson Gentoo Linux Developer & Infra Guy E-Mail : [email protected] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
pgpYlJNlnALFU.pgp
Description: PGP signature
