[gentoo-dev] Re: Making a common sub-profile for no-multilib

[Jonathan Callen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 07/03/2014 12:59 AM, Duncan wrote:
> Jonathan Callen posted on Wed, 02 Jul 2014 19:06:59 -0400 as
> excerpted:
>
>> On 07/02/2014 02:14 PM, Duncan wrote:
>>> Rich Freeman posted on Wed, 02 Jul 2014 09:30:50 -0400 as
>>> excerpted:
>>>
>>>> Some things to think about include multilib (just another
>>>> arch?), systemd, and usr-merge.
>>>
>>> FWIW, systemd with merge to / (/usr being a symlink to . and
>>> sbin to bin) here.  In particular, the merge "just works" with
>>> current portage. I'm no-multilib.
>>>
>> That merge only works because you happened to get lucky, and
>> have portage merge coreutils in a particular manner
>> (/usr/bin/uname installed before /bin/uname).  If portage had
>> installed /bin/uname first, you would have ended up with a
>> /bin/uname symlink pointing to /bin/uname. The same is also true
>> of basename, chroot, cut, dir, dirname, du, env, expr, head,
>> mkfifo, mktemp, readlink, seq, sleep, sort, tail, touch, tr, tty,
>> vdir, wc, and yes.
>
> No, it works because, as I specifically asked the portage folks
> about before I tried it, portage has had symlink merge intelligence
> for some time now.  Apparently well before I asked (in May, 2013,
> according to my portage-devel list archives), some portage dev
> considered the possibility of directory symlinks triggering
> overwrites of targets with the symlinks pointing to them, and
> ensured that portage's qmerge code "just did the right thing."
>
> I did nothing with the answer for some time, but eventually decided
> to try it.  As I was a bit skeptical/careful at first, after doing
> the initial manual moves and thus finding which files existed in
> both target dirs, then deleting the individual file symlinks,
> moving the remaining files to the new location and making the old
> directory a symlink, I equery-belonged the symlinks and manually
> remerged (from binpkg, which still stores the symlinks in their
> usual location in the binpkg tarball) several of the packages one
> at a time, first a non-critical one, then I think coreutils itself,
> just to be sure, then 2-3 others together, and sure enough, it
> "just worked" the way it was supposed to work.
>
> =:^)
>
>> I myself am currently running a system with the opposite merge
>> (/bin, /lib, /lib64, and /sbin are symlinks to /usr/bin,
>> /usr/lib, /usr/lib64, and /usr/sbin) although I do not yet have
>> the sbin -> bin merge yet.
>
> FWIW I decided the single /usr -> . symlink was simpler, and
> besides, I liked the shorter direct paths. =:^)  And I did the /usr
> merge first, thinking I wanted to keep the bin/sbin distinction at
> first, until sometime later I decided to simplify my PATH var to
> remove /usr, and realized I had sbin in my normal user's PATH too.
> Completing the merge would/did allow me to simplify PATH even
> further, and since I has sbin in my normal user's PATH, there
> really wasn't a reason to keep them separate at that point, and I
> was already comfortable with merged bins by then anyway, so it
> wasn't much of a stretch at all.
>
>> I added a post_src_install and post_pkg_preinst hook in my
>> /etc/portage/bashrc to ensure that there are no conflicts before
>> the package is merged and a pre_pkg_setup hook to disarm
>> gen_usr_ldscript (so as not to create a conflict).
>
> That's all unnecessary, because as I said, in general portage "just
>  works" with the merge now, since it's designed to work with pretty
> much /any/ strange site-specific symlinking local gentoo admins
> might throw at it, altho I expect the ldcache stuff is still doing
> a bunch of extra work by going over all the dirs that are actually
> the same thing, and I suspect revdep-rebuild (which I still run
> religiously after every @world update) is doing a bunch of extra
> scanning too.  But as I'm on SSD the extra filesystem IO isn't a
> big issue, meaning it's simply the CPU cycle cost, and so far
> simply spending the extra CPU cycles has been cheaper for me than
> actually researching what I might do about it, so...
>

That is good to know.  I did, however test when a package installs two
(different) regular files into paths that end up symlinked, and found
that portage does break in that case (as the only sensible option at
that point is to fail, as something will be lost in either case).

- -- 
Jonathan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCgAGBQJTtQDKAAoJELHSF2kinlg4eIIP/0Jmia/151IPAAt3oG7OalVr
1SyUSdAchM/cCb6m8uf3BDPIxMQa704Zh/TKd3wAxz64BJGmJtDmEBlAq+04nXnw
UFB+dJVJsphN/X/jS7iln1tVqn8099mntYWG9mjv4nQLXNf6U0H1i9iBQtz+uvi5
9tzO6Ghoen6VvyV7ykI/r2uByI4Y4+anVgXKT2s99akbIWFR9qQuHOHWlcxZxurd
QA17Wfnxene7FfpGtsanORvpiKaQamUo75zXlR7l5FydiANH5QKt1Qw5RZIC/k27
PVc+oV2A+7HJVWHrMqEBwwGyn8LokzzX644TpiL17rTHkGa9jYYnsfwO/mIksEh2
O7HzbHyGjD6yUVbY/G3bxUfjpEi0C02DASSlOrHnDsZf4U5joYf9D//jTFQhCkp8
TtPcU7h4HIlyniberknM/WMqQ8B4lnjlCGNcVoaZtqabQ6YtIV+9eu32Gzd0LP29
TN/MQFm98pRGTwAAoyoq8QzOUUpoEBZP05htsW5UvgSe5CAzfi2Tm2TEsF/ulbMs
IoZBdovmv1mpTnNESJ6rTos9QesAbErV0FQn6NC5WcvtWpTrpiRFf3QeqOCcgpZY
ogH241MJaaxnu3vUdKnCD5zd4UBJOjWaViLKIK29v3pWVAgbMeHhC0inNW6gIZIu
Nn8aKkjoyjyEhyJT9/tj
=3Nrz
-----END PGP SIGNATURE-----