Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.devel > #116145 > unrolled thread

TC decision on ownership of top-level filesystem aliases - #1091995

Back to article view | Back to linux.debian.devel

Contents

  TC decision on ownership of top-level filesystem aliases - #1091995 Matthew Vernon <matthew@debian.org> - 2025-03-04 12:50 +0100
    Re: TC decision on ownership of top-level filesystem aliases -  #1091995 Sean Whitton <spwhitton@spwhitton.name> - 2025-03-06 10:40 +0100
      Bug#1091995: TC decision on ownership of top-level filesystem aliases - #1091995 Helmut Grohne <helmut@subdivi.de> - 2025-03-07 13:10 +0100
        Re: TC decision on ownership of top-level filesystem aliases -  #1091995 Marvin Renich <mrvn@renich.org> - 2025-03-07 14:20 +0100
          Re: TC decision on ownership of top-level filesystem aliases -  #1091995 Helmut Grohne <helmut@subdivi.de> - 2025-03-07 18:30 +0100
        Bug#1091995: TC decision on ownership of top-level filesystem aliases - #1091995 Sean Whitton <spwhitton@spwhitton.name> - 2025-03-09 06:00 +0100
        Debian on /usr (Re: TC decision on ownership of top-level filesystem  aliases - #1091995) Matthias Urlichs <matthias@urlichs.de> - 2025-03-09 09:40 +0100
          Re: Debian on /usr (Re: TC decision on ownership of top-level  filesystem aliases - #1091995) Marco d'Itri <md@Linux.IT> - 2025-03-09 17:50 +0100
            Re: Debian on /usr (Re: TC decision on ownership of top-level  filesystem aliases - #1091995) Matthias Urlichs <matthias@urlichs.de> - 2025-03-11 04:10 +0100

#116145 — TC decision on ownership of top-level filesystem aliases - #1091995

Hello,

In Bug #1091995, the Technical Committe was asked to rule on an issue
that could, under certain circumstances, result in failure of the
base-files package to install or upgrade correctly. Under these
circumstances, systemd will create a symlink from /lib64 to /usr/lib,
which does not match the symlink contained within base-files. base-files
will detect this case in preinst and generate an error, but if it did
not do this then dpkg would instead fail with a less verbose message.

Policy does not currently define ownership of the usrmerge filesystem
aliases, but since trixie base-files has effectively been responsible
for ensuring that these aliases are configured appropriately. This is
therefore a technical disagreement rather than a policy violation.

The Technical Committee affirms that base-files should own all
top-level filesystem aliases, and packages that conflict with this must
be patched in Debian to avoid creating any aliases that conflict with
base-files. In doing so, the Technical Committee overrides the systemd 
maintainers.

For complete details of the discussion, please see
https://bugs.debian.org/1091995

Regards,

Matthew (for the Technical Committee)

[toc] | [next] | [standalone]

#116215 — Re: TC decision on ownership of top-level filesystem aliases - #1091995

[Multipart message — attachments visible in raw view] — view raw

Hello ctte,

On Tue 04 Mar 2025 at 11:46am GMT, Matthew Vernon wrote:

> In Bug #1091995, the Technical Committe was asked to rule on an issue
> that could, under certain circumstances, result in failure of the
> base-files package to install or upgrade correctly. Under these
> circumstances, systemd will create a symlink from /lib64 to /usr/lib,
> which does not match the symlink contained within base-files. base-files
> will detect this case in preinst and generate an error, but if it did
> not do this then dpkg would instead fail with a less verbose message.
>
> Policy does not currently define ownership of the usrmerge filesystem
> aliases, but since trixie base-files has effectively been responsible
> for ensuring that these aliases are configured appropriately. This is
> therefore a technical disagreement rather than a policy violation.

Just to note that the most recent release of Policy sort-of defines
ownership of this, though it is not as explicit as the TC decision:

    Packages must not install files to paths whose first component is a
    name directly under the file system root and which is a symbolic
    link to a directory of the same name under "/usr".  ...  The
    base-files package is an exception, for it installs aliasing
    symbolic links from "/bin" to "/usr/bin", "/lib" to "/usr/lib", et
    cetera.

-- 
Sean Whitton

[toc] | [prev] | [next] | [standalone]

#116257 — Bug#1091995: TC decision on ownership of top-level filesystem aliases - #1091995

Hi Sean,

On Thu, Mar 06, 2025 at 05:39:06PM +0800, Sean Whitton wrote:
> Just to note that the most recent release of Policy sort-of defines
> ownership of this, though it is not as explicit as the TC decision:
>
>     Packages must not install files to paths whose first component is a
>     name directly under the file system root and which is a symbolic
>     link to a directory of the same name under "/usr".  ...  The
>     base-files package is an exception, for it installs aliasing
>     symbolic links from "/bin" to "/usr/bin", "/lib" to "/usr/lib", et
>     cetera.

Thanks for highlighting the additional context. A significant angle here 
is what it means to "install". systemd does not presently install those 
symlinks at package installation time, so it may be argued that it does 
in fact not violate the updated policy in this regard.

Even after the requested change has been effected, systemd will continue 
to create the aliasing symlinks when missing. This kinda is intended as 
a mechanism supporting hermetic-/usr. Longer term, it shall become 
possible to install Debian in such a way that the entire installation 
lives below /usr (though it will not be possible to upgrade such an 
installation due to the lack of /var/lib/dpkg in the initial 
implementation). Then systemd may assemble a system from the 
Discoverable Partitions Specification 
(https://uapi-group.org/specifications/specs/discoverable_partitions_specification/). 
It may locate a /usr filesystem and an empty root partition and 
initially populate the latter. That population step includes creating 
aliasing symlinks such as /bin -> usr/bin. You may argue that this 
constitutes an "installation" and thus violates policy.

Can you clarify how you understand policy here?

I read it as systemd is not performing an installation here and 
therefore does not violate the present policy. If your reading is 
different, we should likely clarify policy on this aspect.

Helmut

[toc] | [prev] | [next] | [standalone]

#116258 — Re: TC decision on ownership of top-level filesystem aliases - #1091995

* Helmut Grohne <helmut@subdivi.de> [250307 07:05]:
> Hi Sean,
> 
> On Thu, Mar 06, 2025 at 05:39:06PM +0800, Sean Whitton wrote:
> > Just to note that the most recent release of Policy sort-of defines
> > ownership of this, though it is not as explicit as the TC decision:
> >
> >     Packages must not install files to paths whose first component is a
> >     name directly under the file system root and which is a symbolic
> >     link to a directory of the same name under "/usr".  ...  The
> >     base-files package is an exception, for it installs aliasing
> >     symbolic links from "/bin" to "/usr/bin", "/lib" to "/usr/lib", et
> >     cetera.
> 
> Thanks for highlighting the additional context. A significant angle here 
> is what it means to "install". systemd does not presently install those 
> symlinks at package installation time, so it may be argued that it does 
> in fact not violate the updated policy in this regard.

Are you saying that systemd creates the symlinks at runtime when it
finds them missing, rather that when the systemd package is installed?
To me, this is a clear violation of the policy quoted above.  "...must
not install..." says nothing about when the installation happens.
Installing a symlink is distinct from installing a package.  The act of
creating the symlink is exactly "installing" it, whether it happens at
package installation or later.

...Marvin

> Even after the requested change has been effected, systemd will continue 
> to create the aliasing symlinks when missing. This kinda is intended as 
> a mechanism supporting hermetic-/usr. Longer term, it shall become 
> possible to install Debian in such a way that the entire installation 
> lives below /usr (though it will not be possible to upgrade such an 
> installation due to the lack of /var/lib/dpkg in the initial 
> implementation). Then systemd may assemble a system from the 
> Discoverable Partitions Specification 
> (https://uapi-group.org/specifications/specs/discoverable_partitions_specification/). 
> It may locate a /usr filesystem and an empty root partition and 
> initially populate the latter. That population step includes creating 
> aliasing symlinks such as /bin -> usr/bin. You may argue that this 
> constitutes an "installation" and thus violates policy.
> 
> Can you clarify how you understand policy here?
> 
> I read it as systemd is not performing an installation here and 
> therefore does not violate the present policy. If your reading is 
> different, we should likely clarify policy on this aspect.
> 
> Helmut
> 

[toc] | [prev] | [next] | [standalone]

#116264 — Re: TC decision on ownership of top-level filesystem aliases - #1091995

On Fri, Mar 07, 2025 at 08:14:00AM -0500, Marvin Renich wrote:
> Are you saying that systemd creates the symlinks at runtime when it
> finds them missing, rather that when the systemd package is installed?
> To me, this is a clear violation of the policy quoted above.  "...must
> not install..." says nothing about when the installation happens.
> Installing a symlink is distinct from installing a package.  The act of
> creating the symlink is exactly "installing" it, whether it happens at
> package installation or later.

You are reading it correctly. systemd is creating /bin, /lib, /sbin and
in some situations also /lib64 when it finds them missing at runtime
(e.g. during system boot from the initramfs before pivot_root). In a
pretty normal installation this code path is not takes. For one thing,
those links tend to exist and existence prevents systemd from touching
them. For another, our default initramfs does not involve systemd.

If we consider this behavior a violation of the present policy. I
believe that we should change it. Having systemd create those links when
missing is crucial for implementing hermetic-/usr and I see little
reason for our policy to forbid that use case.

What was decided by the CTTE here is that systemd must not create links
that are *incompatible* with the ones base-files creates. In particular,
systemd must not create /lib64 -> usr/lib as a result of the CTTE
decision.

Helmut

[toc] | [prev] | [next] | [standalone]

#116311 — Bug#1091995: TC decision on ownership of top-level filesystem aliases - #1091995

[Multipart message — attachments visible in raw view] — view raw

Hello,

On Thu 06 Mar 2025 at 11:25am +01, Helmut Grohne wrote:

> Can you clarify how you understand policy here?
>
> I read it as systemd is not performing an installation here and
> therefore does not violate the present policy. If your reading is
> different, we should likely clarify policy on this aspect.

I read it that way too.

-- 
Sean Whitton

[toc] | [prev] | [next] | [standalone]

#116318 — Debian on /usr (Re: TC decision on ownership of top-level filesystem aliases - #1091995)

[Multipart message — attachments visible in raw view] — view raw

On 06.03.25 11:25, Helmut Grohne wrote:
> onger term, it shall become possible to install Debian in such a way that the entire installation
> lives below /usr (though it will not be possible to upgrade such an
> installation due to the lack of /var/lib/dpkg in the initial
> implementation).

My "build me a Debian image" script has been doing that for two years 
now, simply by moving /var/lib/dpkg to /usr/state/dpkg and bind-mounting 
it back onto /var/lib/dpkg (symlinking won't work).

Presto, a /usr subvolume (I'm using btrfs) that's actually consistent 
when snapshotted.

Granted that some pieces are missing, most notably /boot (which really 
should be populated from /usr (and /etc) instead of being directly 
installed to), but that's irrelevant when your usecase is booting 
containers, and fixable by reinstalling the kernel packages.

-- 
-- regards
-- 
-- Matthias Urlichs

[toc] | [prev] | [next] | [standalone]

#116340 — Re: Debian on /usr (Re: TC decision on ownership of top-level filesystem aliases - #1091995)

[Multipart message — attachments visible in raw view] — view raw

On Mar 09, Matthias Urlichs <matthias@urlichs.de> wrote:

> My "build me a Debian image" script has been doing that for two years now,
> simply by moving /var/lib/dpkg to /usr/state/dpkg and bind-mounting it back
> onto /var/lib/dpkg (symlinking won't work).
How so? My /var/lib/dpkg has been a symlink for a very long time.

> Granted that some pieces are missing, most notably /boot (which really
> should be populated from /usr (and /etc) instead of being directly installed
> to), but that's irrelevant when your usecase is booting containers, and
> fixable by reinstalling the kernel packages.
See https://www.linux.it/~md/text/factoryreset-asg2024.pdf .

-- 
ciao,
Marco

[toc] | [prev] | [next] | [standalone]

#116403 — Re: Debian on /usr (Re: TC decision on ownership of top-level filesystem aliases - #1091995)

[Multipart message — attachments visible in raw view] — view raw

On 09.03.25 17:45, Marco d'Itri wrote:
> On Mar 09, Matthias Urlichs<matthias@urlichs.de> wrote:
>
>> My "build me a Debian image" script has been doing that for two years now,
>> simply by moving /var/lib/dpkg to /usr/state/dpkg and bind-mounting it back
>> onto /var/lib/dpkg (symlinking won't work).
> How so? My /var/lib/dpkg has been a symlink for a very long time.
Huh. It's been sufficiently long ago that I first did this; IIRC I 
simply used a bind mount instead of investigating what replaced the 
symlink. If this has since been fixed (by chance?), so much the better.
>> Granted that some pieces are missing, most notably /boot (which really
>> should be populated from /usr (and /etc) instead of being directly installed
>> to), but that's irrelevant when your usecase is booting containers, and
>> fixable by reinstalling the kernel packages.
> Seehttps://www.linux.it/~md/text/factoryreset-asg2024.pdf .

Ah. Thanks.

-- 
-- regards
-- 
-- Matthias Urlichs

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.devel

csiph-web