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 [email protected]
