Bug#1035904: marked as done (dpkg currently warning about merged-usr systems (revisited) (was: Re: DEP 17: Improve support for directory aliasing in dpkg))

[Debian Bug Tracking System]

Your message dated Tue, 13 Jun 2023 20:01:52 +0100
with message-id <20230613190152.ga12...@srcf.ucam.org>
and subject line Re: Bug#1035904: dpkg currently warning about merged-usr 
systems (revisited)
has caused the Debian Bug report #1035904,
regarding dpkg currently warning about merged-usr systems (revisited) (was: Re: 
DEP 17: Improve support for directory aliasing in dpkg)
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.)


-- 
1035904: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035904
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: tech-ctte
X-Debbugs-Cc: Russ Allbery , Sean Whitton 
, Helmut Grohne , Luca Boccassi 
, debian-d...@lists.debian.org, debian-de...@lists.debian.org

On Wed, 2023-05-10 at 14:36 -0700, Russ Allbery wrote:
> Ansgar  writes:
> > Debian going out of its way to tell derivative users to switch back from
> > merged-/usr to split-/usr is the *opposite* of trying to make things as
> > smooth for them as possible.
> 
> Yes, I agree with that part and I think I objected to that at the time.
> Nonetheless, one bad decision doesn't mean that it is Debian policy that
> we don't care about derivatives or their users.  I think we made a mistake
> there which is not in alignment with our ideals or our goals.  We should
> try to reverse that mistake, not double down on it.

Cool, then let's ask tech-ctte.

Dear ctte, please consider overruling the dpkg maintainer to include
the patch from #994388[1].

Thanks,
Ansgar

  [1]: https://bugs.debian.org/994388#397
--- End Message ---
--- Begin Message ---
Hi Ansgar,

After discussing this at our monthly meeting, we concluded that the 
technical committee isn't going to take action on this at the moment. 
There's a legitimate technical consideration behind the warning, and 
it's necessary for derivatives to ensure that they handle the associated 
scenarios properly. While those underlying technical issues exist, we 
think it's premature for the committee to intervene on this specific 
issue.

Thanks,

Matthew Garrett, on behalf of the Debian technical committee--- End Message ---

Re: DEP 17: Improve support for directory aliasing in dpkg

[Matthew Vernon]

On 26/05/2023 09:24, Luca Boccassi wrote:

On Fri, 26 May 2023 at 08:39, Matthew Vernon  wrote:



Consider: it is consistent to believe that it would have been better for
dpkg not to have had that warning added (quite some time ago now), but
that by now most derivatives that care will likely have patched it out
again (mitigating the harm); and if the current work on dpkg is allowed
to run its course then the warning will probably go away anyway.


That assumes all derivatives track unstable/testing and have taken
action, but it is possible for derivatives to track stable only, and
those would be broken.


I agree such distributions would be left with a confusing disagreement 
between the release notes "only /usg-merged systems are supported" and 
dpkg's warning. I agree this isn't ideal; but the release notes will 
mitigate the risk to such derivatives.


And as I said up-thread (and I'm trying not to repeat myself too much), 
I'm not sure why this is suddenly urgent so late in the release cycle, 
nor that we wouldn't be better off working on fixing the issues around 
dpkg and /usr-merge (which some people are currently doing).


Regards,

Matthew

Re: DEP 17: Improve support for directory aliasing in dpkg

[Luca Boccassi]

On Fri, 26 May 2023 at 08:39, Matthew Vernon  wrote:
>
> Hi,
>
> On 26/05/2023 07:03, Ansgar wrote:
> > On Wed, 2023-05-10 at 14:36 -0700, Russ Allbery wrote:
> >> Ansgar  writes:
> >>> Debian going out of its way to tell derivative users to switch back from
> >>> merged-/usr to split-/usr is the *opposite* of trying to make things as
> >>> smooth for them as possible.
> >>
> >> Yes, I agree with that part and I think I objected to that at the time.
> >> Nonetheless, one bad decision doesn't mean that it is Debian policy that
> >> we don't care about derivatives or their users.  I think we made a mistake
> >> there which is not in alignment with our ideals or our goals.  We should
> >> try to reverse that mistake, not double down on it.
> >
> > My impression is that the tech-ctte disagrees on this point and would
> > not want to reverse the mistake, but double down on it (in your words).
>
> Your impression is incorrect. And assigning motivations to other parties
> during contentious discussions should be done with care if at all.
>
> Consider: it is consistent to believe that it would have been better for
> dpkg not to have had that warning added (quite some time ago now), but
> that by now most derivatives that care will likely have patched it out
> again (mitigating the harm); and if the current work on dpkg is allowed
> to run its course then the warning will probably go away anyway.

That assumes all derivatives track unstable/testing and have taken
action, but it is possible for derivatives to track stable only, and
those would be broken.

Kind regards,
Luca Boccassi

Re: DEP 17: Improve support for directory aliasing in dpkg

[Ansgar]

On Fri, 2023-05-26 at 08:39 +0100, Matthew Vernon wrote:
> > So let me summarize Debian's "official" position as I understand it: we
> > do *NOT* care how dpkg's recommendations will break derivative
> > installations at all; if systems become unbootable, cause data loss,
> > ... now or in the future that is explicitly fine.
> 
> This is also unhelpful (and incorrect).

No, it is correct.

We allow boot-critical parts to refer to files using either the path in
/ or /usr; on systems following the recommendations from dpkg's warning
this might result in non-booting systems.

That is what we sign up to accept by having the warning in dpkg.

Ansgar

Re: DEP 17: Improve support for directory aliasing in dpkg

[Matthew Vernon]

Hi,

On 26/05/2023 07:03, Ansgar wrote:

On Wed, 2023-05-10 at 14:36 -0700, Russ Allbery wrote:

Ansgar  writes:

Debian going out of its way to tell derivative users to switch back from
merged-/usr to split-/usr is the *opposite* of trying to make things as
smooth for them as possible.


Yes, I agree with that part and I think I objected to that at the time.
Nonetheless, one bad decision doesn't mean that it is Debian policy that
we don't care about derivatives or their users.  I think we made a mistake
there which is not in alignment with our ideals or our goals.  We should
try to reverse that mistake, not double down on it.


My impression is that the tech-ctte disagrees on this point and would
not want to reverse the mistake, but double down on it (in your words).


Your impression is incorrect. And assigning motivations to other parties 
during contentious discussions should be done with care if at all.


Consider: it is consistent to believe that it would have been better for 
dpkg not to have had that warning added (quite some time ago now), but 
that by now most derivatives that care will likely have patched it out 
again (mitigating the harm); and if the current work on dpkg is allowed 
to run its course then the warning will probably go away anyway.



Or rather my impression is that they would like to avoid any decision
on the dpkg mess situation. (Though not making a decision when asked is
of course also an explicit decision.)


There is currently a pile of ongoing work and discussion about 
/usr-merge and dpkg (in -devel at least). It seems to me that the right 
thing to do is to see how that work pans out, and let the people doing 
that work do so in peace.



So let me summarize Debian's "official" position as I understand it: we
do *NOT* care how dpkg's recommendations will break derivative
installations at all; if systems become unbootable, cause data loss,
... now or in the future that is explicitly fine.


This is also unhelpful (and incorrect). I do not think the case has been 
made that it is urgent that we remove (or revise) the warning from dpkg 
Right Now; if you want to attempt to do so, please do so without 
impugning those who disagree with you.


Regards,

Matthew

Re: DEP 17: Improve support for directory aliasing in dpkg

[Ansgar]

Hi Russ,

On Wed, 2023-05-10 at 14:36 -0700, Russ Allbery wrote:
> Ansgar  writes:
> > Debian going out of its way to tell derivative users to switch back from
> > merged-/usr to split-/usr is the *opposite* of trying to make things as
> > smooth for them as possible.
> 
> Yes, I agree with that part and I think I objected to that at the time.
> Nonetheless, one bad decision doesn't mean that it is Debian policy that
> we don't care about derivatives or their users.  I think we made a mistake
> there which is not in alignment with our ideals or our goals.  We should
> try to reverse that mistake, not double down on it.

My impression is that the tech-ctte disagrees on this point and would
not want to reverse the mistake, but double down on it (in your words).

Or rather my impression is that they would like to avoid any decision
on the dpkg mess situation. (Though not making a decision when asked is
of course also an explicit decision.)

So let me summarize Debian's "official" position as I understand it: we
do *NOT* care how dpkg's recommendations will break derivative
installations at all; if systems become unbootable, cause data loss,
... now or in the future that is explicitly fine.

Ansgar

Bug#1035904: dpkg currently warning about merged-usr systems (revisited) (was: Re: DEP 17: Improve support for directory aliasing in dpkg)

[Luca Boccassi]

On Sun, 21 May 2023 at 15:51, Ansgar  wrote:
>
> On Sun, 2023-05-21 at 16:25 +0200, Helmut Grohne wrote:
> > On a process level, I think I miss attempts to resolve this with the
> > dpkg maintainer in a constructive way.
>
> The patch was already suggested to the dpkg maintainer and rejected.
>
> > Does anyone mind just closing the bug?
>
> Yes, I do.
>
> Please pass a resolution that you don't want to override the dpkg
> maintainer and that telling derivative users to configure their system
> in a way that will cause breakage is okay to do for packages in Debian.

I do as well. Recently a very strong consensus emerged that even
accidentally causing damage and/or incompatibility to
downstreams/external use cases is strongly frowned upon, to say the
least. Talking the talk is easy, now we have to walk the walk. Both
the warning and the 'unmess' tool cause significant damage and break
cross-compatibility, so they both need to be removed.

A "mind the moratorium" message would be of course very sensible to have.

Kind regards,
Luca Boccassi

Bug#1035904: dpkg currently warning about merged-usr systems (revisited) (was: Re: DEP 17: Improve support for directory aliasing in dpkg)

[Ansgar]

On Sun, 2023-05-21 at 16:25 +0200, Helmut Grohne wrote:
> On a process level, I think I miss attempts to resolve this with the
> dpkg maintainer in a constructive way.

The patch was already suggested to the dpkg maintainer and rejected.

> Does anyone mind just closing the bug?

Yes, I do.

Please pass a resolution that you don't want to override the dpkg
maintainer and that telling derivative users to configure their system
in a way that will cause breakage is okay to do for packages in Debian.

Ansgar

Bug#1035904: dpkg currently warning about merged-usr systems (revisited) (was: Re: DEP 17: Improve support for directory aliasing in dpkg)

[Helmut Grohne]

Hi Ansgar,

I'm speaking with a CTTE hat here, but not representing CTTE consensus.

On Wed, May 10, 2023 at 11:47:42PM +0200, Ansgar wrote:
> Dear ctte, please consider overruling the dpkg maintainer to include
> the patch from #994388[1].

I think we need to reject this request on multiple levels.

On a social level, I see that you are frustrated with how dpkg is being
maintained and how communication does not work out in practice. While
part of that can be attributed to the dpkg maintainer, this goes both
ways and the way you refer this matter to the CTTE without even
attempting to resolve it by other means just serves to deepen that
dispute. I see that the dpkg maintainer has recently contributed
constructively to the discussion about how dpkg can be part of a
solution for the problems resulting from the /usr merge. I have a hard
time saying the same about your interaction here. Therefore, I think
your request should be rejected as not being serious.

On a process level, I think I miss attempts to resolve this with the
dpkg maintainer in a constructive way. The present discussion clearly
shows that dpkg's support for how Debian deals with merged /usr is
lacking. We are dealing with multiple file-loss scenarios (something we
otherwise consider grave) and issuing a warning about such behaviour
seems fine to me. On the other hand, much of the project seems to agree
that the way this warning is worded is far from optimal and evidently
leads to confused users. And while it may seem that any attempt at
resolving may lead nowhere, the same can be said about our dpkg
maintainer's concerns about our /usr-merge strategy and him pointing out
real problems affecting Debian installations in practice. Given the
recent constructive communication, I think it is far from clear that
this option is exhausted. In particular, acknowledging the problems
presented and proposing strategies for dealing with them could go a long
way towards a cooperative solution.  At present, I see the options to
keep and to delete the warning on the table, but there clearly is
unexplored middle ground.  As such, I think your request should be
rejected as not having exhausted the solution space.

On a technical level, Debian's support for merged /usr is currently
founded on the moratorium preventing breakage. Please observe that this
moratorium applies to Debian and Debian only. We have implemented
processes to validate this. If a derivative wants to use merged /usr
(which probably every derivative should), it certainly needs to prevent
breakage in some way - presumably using a similar process. I think that
the cost of patching dpkg is minor compared to the cost of a process
that prevents breakage arising from our merged /usr strategy.  Given
this, a warning-by-default (worded in a better way) for derivatives
actually can be a good thing, because it makes derivatives aware that
they cannot just ignore merged /usr, but have to act. As such, I think
your request should be rejected since the measure is technically
reasonable in principle.

Does anyone mind just closing the bug?

At the same time, I recommend changing the warning. The amount of
feedback we get regarding the warning should make it clear that the
current wording is still seen as offensive and causes confusion. Keeping
the warning in its current form also serves little but deepening the
dispute.

For instance, the wording "going behind dpkg's back" may be considered
technically correct, but it also can be objectively described as passive
aggressive. Just deleting this aspect and instead saying "This system
uses merged-usr-via-aliased-dirs which violates core assumptions of
dpkg." would probably keep the intended message in a less
confrontational way.  Elaborating that file loss is being mitigated by a
process (moratorium) on Debian would also help. Looking into the wiki, a
recommendation of dpkg-fsys-usrunmess should caution that using it now
breaks other tool's assumptions such as systemd and is generally not
being tested with QA anymore.

Even if one were thinking that the warning were appropriate as is,
adapting it again due to community feedback would demonstrate empathy
and be a step towards a cooperative solution.

I think our priority should be finding a way to terminate the
moratorium.

Helmut

Bug#1035904: dpkg currently warning about merged-usr systems (revisited) (was: Re: DEP 17: Improve support for directory aliasing in dpkg)

[Ansgar]

Hi,

On Thu, 2023-05-11 at 00:32 +0200, Ansgar wrote:
> On Wed, 2023-05-10 at 23:47 +0200, Ansgar wrote:
> > Cool, then let's ask tech-ctte.
> > 
> > Dear ctte, please consider overruling the dpkg maintainer to
> > include
> > the patch from #994388[1].
> > 
> > Thanks,
> > Ansgar
> > 
> >   [1]: https://bugs.debian.org/994388#397
> 
> For derivatives based on Debian stable it might be worth having this
> included in the next stable release; this would need a fairly quick
> decision on this issue.

The full freeze is approaching and there has been no progress on this
issue. Does the ctte think a decision before the release is still
possible?

As asked earlier I'm also interested in whether the ctte thinks there
is enough consensus about how this issue should be solved or do we
need a longer discussion to explore the solution space?

I admit not having read all mails in the thread as it went fairly off
topic IMHO.

Ansgar

Bug#1035904: dpkg currently warning about merged-usr systems (revisited) (was: Re: DEP 17: Improve support for directory aliasing in dpkg)

[Ansgar]

On Wed, 2023-05-10 at 23:47 +0200, Ansgar wrote:
> Cool, then let's ask tech-ctte.
> 
> Dear ctte, please consider overruling the dpkg maintainer to include
> the patch from #994388[1].
> 
> Thanks,
> Ansgar
> 
>   [1]: https://bugs.debian.org/994388#397

For derivatives based on Debian stable it might be worth having this
included in the next stable release; this would need a fairly quick
decision on this issue.

Ansgar

Bug#1035904: dpkg currently warning about merged-usr systems (revisited) (was: Re: DEP 17: Improve support for directory aliasing in dpkg)

[Ansgar]

Package: tech-ctte
X-Debbugs-Cc: Russ Allbery , Sean Whitton 
, Helmut Grohne , Luca Boccassi 
, debian-d...@lists.debian.org, debian-de...@lists.debian.org

On Wed, 2023-05-10 at 14:36 -0700, Russ Allbery wrote:
> Ansgar  writes:
> > Debian going out of its way to tell derivative users to switch back from
> > merged-/usr to split-/usr is the *opposite* of trying to make things as
> > smooth for them as possible.
> 
> Yes, I agree with that part and I think I objected to that at the time.
> Nonetheless, one bad decision doesn't mean that it is Debian policy that
> we don't care about derivatives or their users.  I think we made a mistake
> there which is not in alignment with our ideals or our goals.  We should
> try to reverse that mistake, not double down on it.

Cool, then let's ask tech-ctte.

Dear ctte, please consider overruling the dpkg maintainer to include
the patch from #994388[1].

Thanks,
Ansgar

  [1]: https://bugs.debian.org/994388#397

Re: DEP 17: Improve support for directory aliasing in dpkg

[Russ Allbery]

Ansgar  writes:
> On Wed, 2023-05-10 at 13:50 -0700, Russ Allbery wrote:

>> Caring about them isn't the same thing as doing everything they want. 
>> We can both try to make things as smooth for them as possible and still
>> make design decisions about Debian that they may disagree with or that
>> may make some property they want to maintain difficult or impossible. 
>> It's the sort of decision we have to make on a case-by-case basis.

> Debian going out of its way to tell derivative users to switch back from
> merged-/usr to split-/usr is the *opposite* of trying to make things as
> smooth for them as possible.

Yes, I agree with that part and I think I objected to that at the time.
Nonetheless, one bad decision doesn't mean that it is Debian policy that
we don't care about derivatives or their users.  I think we made a mistake
there which is not in alignment with our ideals or our goals.  We should
try to reverse that mistake, not double down on it.

-- 
Russ Allbery (r...@debian.org)  

Re: DEP 17: Improve support for directory aliasing in dpkg

[Ansgar]

Hi Russ,

On Wed, 2023-05-10 at 13:50 -0700, Russ Allbery wrote:
> Ansgar  writes:
> > As far as I understand, we do explicitly *not* care about our
> > derivatives with regard to merged-/usr as some packages in Debian
> > recommend users to move *away* from merged-/usr to split-/usr on
> > derivatives, i.e., to an unsupported fs layout.
> 
> Caring about them isn't the same thing as doing everything they want.  We
> can both try to make things as smooth for them as possible and still make
> design decisions about Debian that they may disagree with or that may make
> some property they want to maintain difficult or impossible.  It's the
> sort of decision we have to make on a case-by-case basis.

Debian going out of its way to tell derivative users to switch back
from merged-/usr to split-/usr is the *opposite* of trying to make
things as smooth for them as possible.

I asked the ctte to consider not telling derivative users to revert
from merged-/usr and was told me that "we [ctte] would not consider
this [change] to be in line with our existing decisions" (informally).

I take that as explicitly not caring that we break derivative users'
systems.

Ansgar

Re: DEP 17: Improve support for directory aliasing in dpkg

[Russ Allbery]

Ansgar  writes:

> So why do we allow changes that require listing all reverse dependencies
> in Breaks then? This is known to be wrong for all non- listed packages,
> e.g., all local/vendor/derivative-specific packages.

Because it's a balance; we don't want to stop making changes, and never
making a backward-compatible change doesn't work, so we do the best we can
with the tools we have.  However, if someone with an out-of-Debian package
tells us that a change breaks it, historically we did add them to Breaks.
We just don't have a good way of discovering this.

> As far as I understand, we do explicitly *not* care about our
> derivatives with regard to merged-/usr as some packages in Debian
> recommend users to move *away* from merged-/usr to split-/usr on
> derivatives, i.e., to an unsupported fs layout.

Caring about them isn't the same thing as doing everything they want.  We
can both try to make things as smooth for them as possible and still make
design decisions about Debian that they may disagree with or that may make
some property they want to maintain difficult or impossible.  It's the
sort of decision we have to make on a case-by-case basis.

-- 
Russ Allbery (r...@debian.org)  

Re: DEP 17: Improve support for directory aliasing in dpkg

[Ansgar]

On Wed, 2023-05-10 at 08:35 -0700, Sean Whitton wrote:
> On Sun 07 May 2023 at 11:14AM +02, Ansgar wrote:
> > Debian's dependency system requires to explicitly declare
> > Depends/Conflicts/Replaces/Breaks, but for obvious reasons we
> > cannot do
> > that for packages outside Debian's ecosystem.
> > 
> > The same is true for diversions/alternatives/* or anything else
> > requiring coordination among all users: the dpkg ecosystem has too
> > many
> > practical limitations to support non-Debian packages on anything
> > but a
> > "it might work" basis (which is usually "good enough").  (This is
> > even
> > true for packages within the Debian ecosystem, especially when one
> > considers partially implemented features like multi-arch.)
> 
> I don't think this is the consensus view.

So why do we allow changes that require listing all reverse
dependencies in Breaks then? This is known to be wrong for all non-
listed packages, e.g., all local/vendor/derivative-specific packages.

> Our derivatives are among our users, for example, and we care about
> them being able to add packages in appropriate ways.

As far as I understand, we do explicitly *not* care about our
derivatives with regard to merged-/usr as some packages in Debian
recommend users to move *away* from merged-/usr to split-/usr on
derivatives, i.e., to an unsupported fs layout.

AFAIR the ctte felt that doing so on derivatives is fine for packages
in Debian (w/o an explicit formal ruling).

Ansgar

Re: DEP 17: Improve support for directory aliasing in dpkg

[Sean Whitton]

Hello,

On Sun 07 May 2023 at 12:03PM +01, Luca Boccassi wrote:

> Sure, this is in the context of the ongoing discussion in the TC about
> revising their side of the advice.

I think it's highly unlikely that we revise it rather than just reissue
it, at the present time, because too many details are unsettled.

> Also, we shouldn't lose sight of the reason why this was issued in the
> first place: it is designed to stop a problem from happening, and that
> problem can only happen when both conditions are true. I can't read
> minds obviously, but I imagine that's the reason the RT advice was
> worded as it was.

It's designed to stop as-yet-unknown problems happening, too.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: DEP 17: Improve support for directory aliasing in dpkg

[Sean Whitton]

Hello,

On Sat 06 May 2023 at 09:47PM +01, Luca Boccassi wrote:

> On Sat, 6 May 2023 at 19:51, Helmut Grohne  wrote:
>>
>> > - the moratorium on moving files from bin/ sbin/ lib/ _and_ to other
>> > packages at the same time is maintained from bookworm till trixie, and
>> > will lifted after trixie ships, and applies implicitly to all the
>> > ~2000 binary pkgs that are affected by the above
>>
>> While the CTTE placed the moratorium until the release of bookworm, the
>> release team extended it beyond, see
>> https://lists.debian.org/e1ocdqk-0005ge...@respighi.debian.org. So you
>> need explicit agreement from the release team on your plan. Failing
>> that, any package that has been forcefully moved is immediately
>> rc-buggy due to failing a release team requirement.
>
> Of course the release team needs to be on board, no questions about
> that. But given the idea is to maintain their decision exactly as it
> stands I wouldn't imagine it would be an issue? Once again, the
> moratorium is explicitly about moving between locations _and_
> packages, in combination, not either/or. From that same email you
> linked:
>
> "Files moving their canonical location between / and /usr (details in
> [1]) *and* from one binary package to another binary package within
> one release cycle remain an RC issue unless dpkg supports it."
>
> I'm proposing to keep this in place as a general rule, with the new
> escape hatch that you devised as the only addition.

Actually, the morotorium is not explicitly only about moving between
both locations and packages.  Firstly, the TC's morotorium does not have
the qualification, restricting *any* movements in data.tar.*:

The Technical Committee recommends that during the Debian 12
development cycle, the maintainers of individual packages should not
proactively move files from the root filesystem to the corresponding
locations in /usr in the data.tar.* of packages. Files that were in
/usr in the Debian 11 release should remain in /usr, while files
that were in /bin, /lib* or /sbin in the Debian 11 release should
remain in those directories.  If files were moved from /bin, /lib*
or /sbin into /usr since the Debian 11 release, they should be moved
back to their Debian 11 locations.

Then secondly, the RT's message is ambiguous, because it says both that
they want the /TC's/ morotorium to remain in place, and also that files
moving between both locations and packages is an RC issue.

Until the RT's position is clarified, I think we should treat the
broader prohibition as what they require.  The TC are going to discuss
this issue at our meeting on Tuesday, and one possible outcome is that
we reissue our version of the broader prohibition.

Stepping back:

I am far from being an expert on the details of merged-/usr.  But one
thing I've noticed is that among the people who have spent the most time
looking into it, the majority think that simple fixes are not going to
be sufficient.  Only a few people who have spent a lot of time on it
still think that the fixes that are required are relatively simple ones.

If the former group are wrong then the transition takes longer than it
needs to, but we don't lose any confidence in the state of our users'
installations.

If the latter group are wrong then we'll probably end up with a longer
transition anyway, and a worse situation for both our maintainers and
our users.  And it's within one of the areas of Debian that we're most
proud of -- completely smooth upgrades between stable releases.

So, I think we should assume the people who are more worried are right,
for the time being.  We lose little in doing so.

-- 
Sean Whitton


signature.asc
Description: PGP signature