Re: [gentoo-user] Re: portage directory ownerships?

[Alan McKinnon]

On 16/09/2015 15:46, james wrote:
> Neil Bothwick <neil <at> digimed.co.uk> writes:
>
>
>
>>> Here, all of /etc/portage is root:root
>>> The tree and all overlays are portage:portage
>
>> Just to add some confusion to the mix
>
> <snip>
>
> Good example and it got me thinking....
>
>> So some are portage:portage, some are root:root - all use /var/portage
>> for $PORTDIR so that's not an issue. One of the portage:portage ones is
>> the one that syncs with the mirrors and acts as an rsync host for the
>> others, this may or may not be significant.
>
> I might swith to /var/portage on a new install. Whats the pedantic
> reasons for for it? On an SSD for speed ? tmpdir? I'm curious, so tell me more.

Nothing to do with tmpdir stuff.

/usr has always been something that must mountable read-only and still
work should the user want it that way.
/var is where data goes that can change. The tree is a database, it can
change, and does every time you sync.

The tree was in /usr/portage for years for NO OTHER REASON than that's
where FreeBSD put it (portage is based off/inspired by FreeBSD ports).
That works on FreeBSD nicely but strictly according to Linux conventions
and FHS should have been in /var all along.

You can put the tree any place you like, just modify PORTDIR to suit
plus a few other bits (eg profile symlink in /etc/portage). The switch
to /var is only a change to the hard-coded default


>
>
> 1. So 'the tree' (/usr/portage/) is portage:portage  OK.
>
> 2. and /etc/portages is root:root  except for distfiles (root:portage) OK.
>
> 3. and /var/lib/layman  and subdirs are  root:root  ???
> Note, these are the overlays I use but do not hack on.

That's fine. If you only --sync as root it all works out

>
>
> 4. and /usr/local/portage is    james:james
> this where I hack on codes that are mostly other overlays that
> need enhancements or raw codes I am processing into ebuilds.
>
> 5. /usr/local/experimental is  james:james
> where I working on codes that can compile
> install or be removed without the baggage of portage/ebuilds. It
> will be for embedded and cluster/cloud/vm movements of binaries
> to attach directly to the 4.x kernel, dynamically.
> I'm working on a new build semantic with DAGs, Tup, ninja and CheckInstall
>
>
> So I can ignore (5) in make.conf. But I'm now getting ebuilds installed
> in /usr/local/portage, I think because of this line in my make.conf::
>
> PORTDIR_OVERLAY="source /etc/portage/repos.conf/layman.conf"
> PORTDIR_OVERLAY="/usr/local/portage"

No man, rip that shit out. Delete both lines and replace with entries in
/etc/portage/repos.conf/

There was a news item on 2 Feb that gives full details.
Then emerge layman with use="sync-plugin-portage"

And btw, your second line overrides and replaces the first.

> For goals of 1-5 what are improvements (any and all suggestions) on
> make.conf I should make?  I need to ensure that overlays that I do
> not modify stay separate for the ebuild I modify. In fact some packages
> are in both 3 and 4.  I use git to seed category 4 so what caveates
> do I use to ensure that git only seeds categroy 4 packages (ebuilds)once
> and does not contaminant my 'old school; vim' hackery.

Edit only inside the overlay you want to change. If you have another
overlay that is essentially read-only (or you don't change), and you do
edit it, well then you just changed it and the computer will follow your
lead :-)

so vi then git add/commit/push the stuff you edit.

Or maybe I don't grok what you mean here

>
>
> I think this is the only change I need::
> PORTDIR_OVERLAY="/usr/local/portage" ==>
> PORTDIR_OVERLAY="/var/lib/layman"

No. DoItRite as above. That PORTDIR_OVERLAY crap never did work right -
all overlays were essentially considered equal and it would be pot luck
where your next ebuild comes from....


> Or does layman and git (syncs) know where to place things. I do use
> 'git clone' to seed category 4 packages-->ebuilds and will
> eventually be use more of git's features to push out updates.

layman doesn't know anything other than what's in it's config. There's
no magic. If you tell it a repo in mastered at place X, and you make
changes to X, layman will sync those changes.

Don't use 'git clone' for this. A clone is your first checkout. Rather
push the stuff you edit and pull updates from there with layman

>
> I just gotta get this straight, consistent and keep things seperate
> in my mind, because being an old fart, reading lots of codes, sometimes
> I forget the origins of hacks. (yea yea document the code you old hack)



-- 
Alan McKinnon
alan.mckinnon@×××××.com