[Discuss] Debian 12 vs. WSL 1

[grg]

On Fri, Jun 16, 2023 at 07:18:17PM -0500, Derek Martin wrote:
> On Fri, Jun 16, 2023 at 07:07:19PM -0500, Derek Martin wrote:
> > No. A symlink solves that problem if it's a concern in your
> > environment--it never has been in any of mine,
> 
> FWIW, I'd venture a guess that it HAD been at one point, but someone
> solved it in the obvious way before I came along, and it never
> intruded upon my peace. =8^)

I think the usrmerge proponents claim that it's working for you not because
it was some trivial/"obvious" tweak by one person at one point beyond your
event horizon, but rather because developers/package maintainers exert
*constant* effort to keep it working for you.  porting any software or
applying any patch that references a bin/sbin/lib path may require a fix
pre-usrmerge, and no longer will post-usrmerge.

for instance, I read that when ubuntu introduced usrmerge by making it the
default for new installs but optional for upgrades, the package builder/
distro test environments (installed fresh) very quickly began distributing
packages which then failed on non-usrmerged systems.  so they had to
un-usrmerge their build/test environments to catch these path problems and
bounce them back to package maintainers to fix.  (and fwiw I agree with
rich here that it's a good practice to use explicit paths especially in
software for public use, and this seems to show that others do too.)

so this change is being pushed by package/distro maintainers to make *their*
lives easier - which is totally fair, imho, especially if the change is
transparent to everyone else.(*)  without forcing a usrmerge, they're
requiring this ongoing effort forever, which is a very long time...

derek, I'm curious whether usrmerge has "intruded upon your peace" -- what
problems have you run into with it, what extra work has it caused you?
or has the change been pretty seamless for you as they intended?


On Fri, Jun 16, 2023 at 07:07:19PM -0500, Derek Martin wrote:
> No. A symlink solves that problem if it's a concern in your environment

adding the symlinks you mention is one of the ways to implement usrmerge
("symlink farms", a vociferously championed approach that ultimately lost
out to "aliased dirs").  but given that a major benefit of a distro is
having a standardized and functional base environment, why would you want
every user to do this on their own rather than having the distro do it in a
single unified way for everyone, especially if it can do so transparently?(*)


> Of course, if said development occurs on platforms that don't merge,
> then it is those who have whom will have portability be "harder."

I don't think that's right.  something coded to a pre-usrmerge environment
"should just work" on post-usrmerge.  taking the example of /bin vs /usr/bin:
 * pre-usrmerge, /bin and /usr/bin may have different contents.  a binary
   may exist in one but not the other, or /bin/foo and /usr/bin/foo may
   both exist but be completely different programs.  you must get the
   specification of /bin vs /usr/bin precisely correct.  (but what's correct?
   e.g. where is md5sum?  is it in the same place in every *nix?  every distro
   of a given *nix?  every release of that distro?)
 * post-usrmerge, /bin and /usr/bin are identical; you can specify either
   one and get the same results, both work.
so whichever one the pre-usrmerge developer specified, it works post-usrmerge.


> It basically requires everyone to get on board, causing a whole bunch
> of arguably useless work, for what I still think is--not none at
> all--but not a particularly compelling benefit.

well, their idea is that a fresh install or a distro upgrade would do this
automatically for everyone, so there should be no work for any end user.(*)
and the "everyone" who needs to be on board is only those who maintain
distros and sub-distros.


--- personal tribulations & gripes follow ---

(*) I keep starring the places where I've repeated the idea that this should
be a noop for end users, because although that might even be true for the
great majority of users, it's not true for 100%.  rich hit a case which
required extra effort from him, and he found an elegant solution.  I hit a
case which required extra effort from me, and I ended up bricking a remote
server.  I recommend following rich's example rather than mine ;)

my beef is that the (ubuntu/debian) perl script that executed the usrmerge
is pretty crappy.  I don't know why this particular system gave it problems
- perhaps because it's been around for a half dozen years and upgraded many
times (all ubuntu), and the script didn't account for things that were
happening that many releases back?  in any case do-release-upgrade died with
"FATAL ERROR: Both /bin/foo and /usr/bin/foo exist."  (I forget which 'foo'
was first, I went through this many times with many different 'foo's.)
yeah, so??  that doesn't seem so bad, much less fatal...  at first I didn't
even understand why it or I should care.

after figuring out what this was all about, I looked at the perl script to
track down the fatal error, but it crappily output this identical message
in many places in the code for different causes.  I ended up hacking their
script to be more informative in its death, then to fix some basic stuff
like necessary quoting they'd missed, then to actually handle the cases it
was failing on (some were hard links, some were symlinks, I think it
handled some links in one direction but not the other, in some there were
two identical copies of the file -- a non-crappy script should be able to
handle all those.  in a few cases there were two different files, which the
script shouldn't try to handle, but at least it should tell you what's
going on).  they really could have done a much better job on this script.

one of the failures was on ld-linux-x86-64.so.  I knew that without that
where it's expected, absolutely *nothing* will work.  and I knew how to
sequence my operations so that every intermediate step would keep the lib
accessible (both places), whether I was trying hard links or symlinks or
copies.  and I did it successfully several times.  but as I was playing
with the different arrangements trying to get something that the perl
script would accept, on one of the trials I mistyped a filename and that
was all she wrote.  I had to get hands on this remote machine and boot from
recovery media to fix my mistake.  so that I could then keep trying to make
their perl script happy, one pair of files at a time.  while this hiccup
was self-inflicted pain, it sure would have been nice if the usrmerge
script handled enough on its own that I wouldn't have had to mess with
ld-linux-x86-64.so.

so while I support making maintainers' lives easier via usrmerge, and I
like the post-usrmerge system better than pre- (did you catch the part
where I found that my system had different binaries with the same names in
/bin and /usr/bin?), I would really have liked the usrmerge proponents to
have written a much less crappy usrmerge script and made it a whole lot
better at usrmerging.

my 2c.
--grg