TL;DR: I think I understand one of Ian's points. I explain, but do not
believe it is compelling as an argument to switch direction.
>>>>> "Helmut" == Helmut Grohne <helmut@subdivi.de> writes:
>> I think "package management" is the wrong term here. It's not
>> just our tools and packages that are affected. All forms of
>> operating system management are affected: anything that changes
>> the software, and not just its configuration.
>>
>> Affected tooling includes not just our .debs, but also remote
>> configuration management systems like Ansible, image construction
>> (Dockerfiles), and 3rd-party software installation progrmas
>> (including both 3rd-party .debs and 3rd-party script-based
>> installation systems).
Helmut> I don't follow the reasoning. Much of the tasks you'd carry
Helmut> out with (wlog) ansible - even when updating files - will
Helmut> continue to work in the aliasing layout. The reason that
Helmut> dpkg is more affected is that it has an inventory of files
Helmut> and reasons about their ownership in terms of
Helmut> packages. That's not how any kind of configuration
Helmut> management operates. If you just "make install" something,
Helmut> chances are that it'll just work with an aliasing layout
Helmut> even when installing with --prefix=/. I continue to argue
Helmut> that the problems we are seeing are quite specific to dpkg
Helmut> in large parts.
I spent some time with Ian's paragraph you quote above trying to
understand it, and I think I got somewhere.
I considered replying yesterday but decided against, because I think we
are already seeing these effects, and have been seeing them long enough
that we would have a good feel for how serious the problems are.
I do think that configuration management does have enough of an
inventory of files and reasoning about structure that some of these
problems could arise. I agree that configuration management does not
typically reason in terms of packages.
But mechanisms like
* ADD/COPY in Containerfile
* The rsync module in ansible
* The file module in Ansible
* various inventories related to modification detection in
configuration management do reason about the filesystem.
I don't know what would happen if I did
hosts: lots
remote_user: root
name: Does this shoot me in the foot
tasks:
- rsync: src=install_root dest=/
where install_root has a bin directory containing a couple of scripts.
I don't know if rsync will replace a symlink with a directory, or will
just write through the symlink in that situation.
If rsync happens to write through the symlink, there's probably some
other tool somewhere else that replaces the symlink.
And when an admin does that, they get an unbootable system, and fix
their playbook/whatever.
Similarly, I bet someone somewhere has integrity management scripts that
want to look at what pam modules are installed under /lib/security, and
depending on how it worked,
they had to adjust the config when that moved to
/lib/security/x86_64-linux-gnu and then again some of them had to adjust
when /lib became a symlink. And they were probably frustrated during
the time when new installs had /lib as a symlink and upgrades did not.
Similarly, I bet you can run into trouble with apparmor profiles if you
try to profile /bin/python rather than /usr/bin/python or similar.
I bet people who had custom selinux policies had to adjust their
labeling rules and again some of them probably found the mixed state
where upgraded systems behaved differently than installed systems
frustrating.
I seem to recall having to make some minor adjustments at my day job
related to usrmerge back in the buster/bullseye time frame.
I don't remember what they were.
I think we've already committed to this pain, and I think we have enough
of a window into that commitment that it doesn't seem to be very much
pain.
I mean spread across all our users, yes people have had to spend
hundreds or thousands of hours dealing with this.
But that's true with any upgrade.
If we move back--if we unwind--things would get much much worse WRT
this type of pain for a while.
I think many more things would be sensitive to /bin/perl being a symlink
than to /bin being a symlink.
You could get into situations where /usr/bin/perl and /bin/perl were
both files and differed.
You could get into situations where /bin/perl vanished on one system.
Etc.
And if we actually try to have a symlink flower patch rather than a
symlink farm, we are left with the pain of where things live differing
between distributions and releases in a distribution.
Mostly all we have left is the dpkg database.
That pain will only affect people producing debs, which isn't just us.
And yes, it will dis proportionally affect people who don't have our
infrastructure and the ability to catch problems. Perhaps we should
think about ways to mitigate that.
There will be other smaller pains; if someone else had a system like
update-alternatives, they would need to be consistent in how they
address files within that pain.
Aliasing does make that worse.
On the other hand, symlinks have been around throughout the lifetime of
Linux, and I think sysadmins do have a feel for how they work.
Attachment:
signature.asc
Description: PGP signature