On 2023-04-26 10:34 +0100, Luca Boccassi wrote:
> On Wed, 26 Apr 2023 at 10:11, Simon Richter <s...@debian.org> wrote:
>>
>> What I'm mostly concerned about (read: have not verified either way)
>> with /lib/ld.so and /bin/sh is what happens when dpkg learns of /bin and
>> /lib as symlinks -- because right now, the symlinks created by usrmerge
>> are protected by the rule that if dpkg expects a directory and finds a
>> symlink, that is fine because that is obviously an action taken by the
>> admin.
>>
>> But if dpkg sees a package containing these as symlinks, then this is
>> entered into the dpkg database, and subject to conflict resolution, and
>> for that, a separate rule exists that directory-symlink conflicts are
>> resolved in favour of the directory, so the interaction between a newer
>> base-files packages shipping /lib as a symlink and an older or
>> third-party package containing /lib as a directory (e.g. a kernel
>> package from a hosting provider) could overwrite the /lib symlink.
No, this does not change anything. The dpkg database currently does not
even record if a pathname in it corresponds to a symlink, a directory or
something else. See also Policy §6.6.4 :
,----
| A directory will never be replaced by a symbolic link to a directory or
| vice versa; instead, the existing state (symlink or not) will be left
| alone and "dpkg" will follow the symlink if there is one.
`----
>> It might be possible to avoid that by never shipping /lib as a symlink
>> and always creating it externally, but I still think that's kind of
>> wobbly.
>
> IMHO we should not ship the top-level symlinks in a package. The
> reason for that is to allow the use case where /usr is a separate
> vendor partition and / is either a luks volume or a tmpfs, and thus
> the top-level symlinks are ephemeral and re-created on boot on the
> fly. If they were part of a package, that would get awkward to say the
> least.
> I really would like to move toward the direction of having exclusively
> /usr and /etc shipped in data.tar, and everything else created locally
> as needed, and that includes files in /.
This means that you need special code in dpkg to preserve these top
level symlinks, as otherwise they are going to disappear with the last
package that contained these as directories, instantly hosing your
installation. I am pretty sure the dpkg maintainer will not like this.
Cheers,
Sven
