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

Groups > linux.debian.bugs.dist > #1236368 > unrolled thread

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

Back to article view | Back to linux.debian.bugs.dist

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  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
      Bug#1091995: TC decision on ownership of top-level filesystem aliases - #1091995 Sean Whitton <spwhitton@spwhitton.name> - 2025-03-09 06:00 +0100

#1236368 — 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] | [next] | [standalone]

#1236552 — 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]

#1236820 — 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] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web