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 488011393F1 for ; Wed, 16 Sep 2015 14:20:09 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E5C6421C01B; Wed, 16 Sep 2015 14:20:01 +0000 (UTC) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id A001CE088B for ; Wed, 16 Sep 2015 14:20:00 +0000 (UTC) Received: by wicge5 with SMTP id ge5so76937451wic.0 for ; Wed, 16 Sep 2015 07:19:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=X4o0KB5hXApKcpDoqkA5qcBGFydztuXQ19iB69FvRrs=; b=ZhFivnfzWaKBo7xmLyWnryu4ewIB+likVm4Aop5cxAWXvFEwjPFL6S3cxZ1aB3aJNZ vjcIcXIhtGjnDXl9HcH/OhQUae2RfBLqesw+oKVdnNNy163YJLFkfyR9Ayxm4BD0ipKI 9x2OWXblHvFz8hswsmxwyVCks/2KG7dZaffzsufKGmV+F3Xvn4rls2fRnLz6TQ66dy5M +H80vEYD0bnov8vWGVkRcSbpXBTp/RzXK/u+Hz0lmDrRJOydD2ijEQEH7xsjaN/Crlhf d7o7rMCCKbk2ruky1uNADsVM3ZKLC3LsxJvidlaKoCGhPthYIxqM73CLuMjEPZX9SP44 u/EQ== X-Received: by 10.180.90.107 with SMTP id bv11mr19820310wib.69.1442413199425; Wed, 16 Sep 2015 07:19:59 -0700 (PDT) Received: from [172.20.0.41] ([105.210.58.210]) by smtp.googlemail.com with ESMTPSA id lh3sm26791385wjc.44.2015.09.16.07.19.57 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Sep 2015 07:19:58 -0700 (PDT) Subject: Re: [gentoo-user] Re: portage directory ownerships? To: gentoo-user@lists.gentoo.org References: <55F87EAB.20101@gmail.com> <20150916085740.0a7cb2a3@digimed.co.uk> From: Alan McKinnon X-Enigmail-Draft-Status: N1110 Message-ID: <55F97A7C.6070906@gmail.com> Date: Wed, 16 Sep 2015 16:19:40 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 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 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Archives-Salt: c42e4458-661d-41af-a988-e4fabb2b5c20 X-Archives-Hash: 1d672b2455ccd4d77f1d39d7bbaabda3 On 16/09/2015 15:46, james wrote: > Neil Bothwick 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 > > > > 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@gmail.com