Re: [gentoo-dev] Gentoo stats server/client @ 2009-06-21

[Robin H. Johnson]

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     : robbat2@g.o
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85