Your message dated Sun, 10 Apr 2022 09:49:37 +0200
with message-id <ylkmessrkufxt...@thunder.hadrons.org>
and subject line Re: Bug#1008489: dpkg: postinst should not warn about Debian's
default (and soon only supported) filesystem layout
has caused the Debian Bug report #1008489,
regarding dpkg: postinst should not warn about Debian's default filesystem
layout
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
1008489: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008489
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: dpkg
Version: 1.21.2
Severity: important
Hi,
I think the warning emitted by dpkg's postinst script about Debian's
default filesystem layout is not appropriate and at least partially
misleading. Several other people agreed with this sentiment.
So I would like to ask the dpkg maintainers to drop this warning.
This includes the slightly differently worded version in 1.21.3.
Ansgar
--- End Message ---
--- Begin Message ---
Version: 1.21.7
On Sat, 2022-04-09 at 17:03:18 +0200, Ansgar wrote:
> On Sat, 2022-04-09 at 16:28 +0200, Guillem Jover wrote:
> > On Sat, 2022-04-09 at 15:47:17 +0200, Ansgar wrote:
> > > To clarify due to misunderstanding that seem to have happened:
> > >
> > > - Merged-/usr is planned to become the only supported layout for
> > > Debian
> > > in the future, cf. [1].
> >
> > Perhaps I indeed misunderstood something, but this seemed pretty
> > clear to me (from [T]:
>
> I'm not sure what you mean by "this"? The decision to only support the
> merged-/usr filesystem layout in the future?
In another mail you wrote:
,---
> | The TC ruling stated that Debian supports for now both layouts
> So maybe the dpkg maintainer just missed that we decided to only
> support merged-/usr starting with bookworm?
> Guillem, please read https://bugs.debian.org/978636#178, relevant part
> quoted below:
> | The Technical Committee resolves that Debian 'bookworm' should
> | support only the merged-usr root filesystem layout, dropping support
> | for the non-merged-usr layout.
> Maybe the misunderstanding will be resolved with this.
`---
So to me this seems it pretty clearly implied that I perhaps had "missed"
or "misunderstood" that the TC had ruled that bookworm would not support
both layouts, based on an old ruling.
I then provided a quote from the TC latest ruling, where it seems it
pretty clearly stating current testind/sid and bookworm, will indeed
still support both layouts. So based on that, both your previous
assertions (re bookwork and me misunderstanding the TC ruling) seem
incorrect to me?
> > - Because Debian 11 installations with the non-merged-/usr layout
> > already exist, all packages in Debian 12 should be installable
> > onto a non-merged-/usr system along with their dependencies, and
> > work correctly on the resulting system.
>
> Packages in Debian 13 might no longer work correctly on legacy split-
> /usr installations. Telling Debian 12/bookworm users to convert systems
> to such a layout thus breaks their upgrade path to Debian 13 (including
> partial upgrades) and should not be done.
(And here you are now shifting to Debian 13, fine.)
If this is related to "my train of thought" mail, then the rationale
there (in case it was not already clear from the text itself) was that,
f.ex. in the same way we already have several people (which otherwise
hold an ambivalent view on merged-/usr) that have stated they are
currently not switching their testing/sid systems using usrmerge,
because they are concerned about it breaking dpkg. I didn't see why if,
say, these same people installed a new system, they'd not be doing the
same trade-off. Which seems fair to me, if the options are a currently
supported layout (non-merged-/usr) in Debian (by TC ruling) and a working
dpkg, or a currently supported layout (merged-/usr) in Debian (also by
TC ruling) and a broken dpkg. Obviously when Debian 13 is out (or even
earlier), all these people will have to decide what to do if they plan
to upgrade. You might disagree whether what these people might decide
to do on their system is wise, or a worse trade-off, but IMO that's
still something they should had the option to decide on for *their*
systems. And in the end this was just a _warning_, not an error that
forbade upgrade or similar (which would have been rather inappropriate),
people have ignored and do ignore warnings all the time all over the
place, if they deem them irrelevant to them.
Otherwise if the above was a comment about the current state, then let
me just repeat that dpkg does not even emit such warning on Debian
anymore.
> [ Derivatives ]
> > I'm not sure how this is a concern for Debian, TBH.
>
> Any such problems will by default also happen on derivatives that don't
> identify and patch affected packages. So I think an opt-in for this
> warning is the better choice for derivatives that want to do so.
It's way easier for dpkg downstreams to silence it than to notice they
might want to opt-in. There are also of course other dpkg downstream
that are used on systems not based on Debian (or derivatives). I have
no problem adding the current Debian context into the dpkg FAQ, so I'll
be doing this when I have a moment. I might also probably add a similar
note to the dpkg-fsys-usrunmess man page, even though in general I try
to make them as distro-agnostic as possible.
I still don't see how this is a concern for Debian. Nor how the Debian
TC could claim "jurisdiction" over this, given that derivatives are not
bound by it, nor they are bound by what you or me might think is best
for them. As I mentioned I'm open to reevaluating as things progress
and how downstreams react to this. Also Debian has not even released
version 12 yet and the current status (either the warning, any
hypothetical dpkg support, or even how such a transition will happen
in Debian) is not really yet set in stone, and things might evolve
over time, and can be modified if necessary.
So the "NMU threat" or involving the TC over the above, seems completely
out of place and an attempt to overreach.
I consider what was requested was already resolved in dpkg 1.21.7,
thus closing it.
Guillem
--- End Message ---
