Bug#839046: debootstrap: enable --merged-usr by default

[Raphael Hertzog]

On Tue, 13 Feb 2018, Julien Cristau wrote:
> On 02/13/2018 04:29 PM, Raphael Hertzog wrote:
> > I believe that we have had quite some testing already last time and I
> > would be surprised if we got many more RC bugs on dpkg that had to be fixed
> > on a short timeframe. I guess nobody can give you any assurance but
> > I'm sure that you can downgrade those bugs pointing to this discussion
> > and showing that this was part of the deal.
> 
> If we break user systems we don't get to downgrade bugs on the basis
> that "we knew we were doing a half assed job with this transition".
> That's not part of the deal we're making with our users.

Granted, but RC bugs against dpkg does not translate into "break user
systems". I would be very surprised if we found out a tool using dpkg
--search that would break the system on which it is running because
it did not get an answer to a specific dpkg --search query.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#839046: debootstrap: enable --merged-usr by default

[Julien Cristau]

On 02/13/2018 04:29 PM, Raphael Hertzog wrote:
> I believe that we have had quite some testing already last time and I
> would be surprised if we got many more RC bugs on dpkg that had to be fixed
> on a short timeframe. I guess nobody can give you any assurance but
> I'm sure that you can downgrade those bugs pointing to this discussion
> and showing that this was part of the deal.
> 
If we break user systems we don't get to downgrade bugs on the basis
that "we knew we were doing a half assed job with this transition".
That's not part of the deal we're making with our users.

Cheers,
Julien

Bug#839046: debootstrap: enable --merged-usr by default

[Raphael Hertzog]

On Mon, 12 Feb 2018, Ansgar Burchardt wrote:
> Guillem Jover writes:
> > In any case, I looked the other day into implementing the
> > --map-pathname option for dpkg-query, and I've got most of the code
> > ready. The problem is that this requires adding support for config
> > files and config fragments to dpkg-query, which has the additional
> > problem of making it possible to mess with the --showformat option
> > and breaking the expectations from maintscripts, for example. The
> > other problem is with the search behavior changing depending on the
> > packages providing those mappings being installed (because dpkg would
> > certainly not provide them).
> 
> So who should provide them?  debootstrap?  base-files?

It certainly makes sense for debootstrap to create those files given it
creates the symlinks in the first place.

An alternative solution could be to reuse the usrmerge package and let
debootstrap install this package if it exists. That way the usrmerge
package would exist until Debian switched entirely to put everything into
/usr/bin.

> The correct long-term fix is probably for packages to eventually install
> to the location in /usr anyway.  That doesn't work without some
> transition period of 1-2 releases though.

Ack.

On Mon, 12 Feb 2018, Guillem Jover wrote about usrmerge:
> This seems like a nice PoV for people to play with it, in the same way
> local admins can use, to some extent, symlinks to redirect subtrees to
> other mount points, but I don't see how this can be seen as a
> production-ready solution shipped by default, TBH.

Note that the change in debootstrap does not install usrmerge currently.
It only creates the required symlinks.


But this is enough to confuse "dpkg -S". This used to break dpkg-shlibdeps
and was the main reason for the initial revert. Fortunately dpkg-shlibdeps has
been fixed to try multiple paths until it can find the package owning the
library.


It might be that we will find other tools confused by "dpkg -S" non-answer
on some /lib/* or /usr/lib/* paths and some end users will definitely be 
surprised by
this.

Obviously we can document the problem in release notes but it would be
better to have a clean solution like suggested by Guillem:

> In any case, I looked the other day into implementing the
> --map-pathname option for dpkg-query, and I've got most of the code
> ready.

If this is forthcoming in the buster timeframe, it seems reasonable to
go ahead and re-enable the merged-usr by default. However to be able to
ship the new configuration files once their format is known, it would be
better for debootstrap to install a package whose role will be to provide
those configuration files ASAP after dpkg starts to support them.

> The problem is that this requires adding support for config
> files and config fragments to dpkg-query, which has the additional
> problem of making it possible to mess with the --showformat option
> and breaking the expectations from maintscripts, for example.

Forbid those options there? Do not parse those files if you detect
an environment variable DPKG_RUNNING_VERSION?

> The other problem is with the search behavior changing depending on the
> packages providing those mappings being installed (because dpkg would
> certainly not provide them).

That's the whole point of it so I would not consider this a problem.

> So I'll eventually try to find a solution for the dpkg-query issue,
> because it's a long-standing paper-cut in dpkg for local admins. But
> I'd not be very amused if this hack is enabled by default again and
> suddenly RC bugs start popping up in dpkg again, and people start
> pressuring with RCness to get those fixed again because well, it's
> obviously breaking people's systems…

Are you considering both "usrmerge" and "debootstrap creating symlinks" as
hacks even once they would provide mapping data for dpkg --search?

I believe that we have had quite some testing already last time and I
would be surprised if we got many more RC bugs on dpkg that had to be fixed
on a short timeframe. I guess nobody can give you any assurance but
I'm sure that you can downgrade those bugs pointing to this discussion
and showing that this was part of the deal.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#839046: debootstrap: enable --merged-usr by default

[Ansgar Burchardt]

Guillem Jover writes:
> In any case, I looked the other day into implementing the
> --map-pathname option for dpkg-query, and I've got most of the code
> ready. The problem is that this requires adding support for config
> files and config fragments to dpkg-query, which has the additional
> problem of making it possible to mess with the --showformat option
> and breaking the expectations from maintscripts, for example. The
> other problem is with the search behavior changing depending on the
> packages providing those mappings being installed (because dpkg would
> certainly not provide them).

So who should provide them?  debootstrap?  base-files?

The correct long-term fix is probably for packages to eventually install
to the location in /usr anyway.  That doesn't work without some
transition period of 1-2 releases though.

Ansgar

Bug#839046: debootstrap: enable --merged-usr by default

[Ansgar Burchardt]

Ian Jackson writes:
> Also, I fear that unless we provide a straightforward way to retain
> separate /usr, including an appropriate d-i command line option, we
> will get further pushback and anger from traditionalists.  We risk
> reopening old wounds (see some of the less temperate responses earlier
> in the thread Ansgar links to as [1]).

There were 11 mails in the thread I linked as [1] in my initial mail.
None were really negative, just one person wondering if this means /
and /usr on separate filesystems is no longer supported (even though I
explicitly said it is in my initial mail).

Also, switching to merged-/usr, but still supporting non-merged-/usr
beyond a transition period means one uses one of the benefits for
maintainers no longer having to care where to install libraries or
programs (or worse: having to move them between / and /usr because
someone would like to use some additional program in early boot or a new
upstream release has support for some new feature requiring a library in
/usr).

I assume the less temperate responses are ones as [no argument]?  I
don't believe that one shouldn't base any decisions on less temperate
responses someone makes on the internet.  That way no change ever could
be implemented.  (What happens when I write less temperate responses to
the less temperate responses calling a proposal shit without any
argument?  Do I invalidate their less temperate response too or is that
reserved to the initial less temperate response?)

I strongly prefer technical reasons instead, such as the issue with
`dpkg -S` that was mentioned by Guillem.

  [no argument]: https://lists.debian.org/debian-devel/2016/01/msg5.html

[...]
> Finally, I have to say that I think that this summary from Ansgar
> is not really accurate:

I think that your summary is far less accurate than mine ;-)

>> As mentioned earlier, I would like to see --merged-usr enabled by
>> default for Debian Stretch.  The last discussion on -devel@[1] was
>> quite positive; I had some additional positive feedback on IRC.
> ...
>> [1] 
>
> That is a link to a message from Russ which mostly explains why
> mounting /usr early (ie in the initramfs, by default) is a good idea.
> That has now been implemented and has caused very little push-back.

No, that's a link to a message by me.

> But this bug report requests something entirely different: it is about
> actually moving the contents of /bin into /usr/bin, etc.

That is also what the linked mail is about.

> It is also not fair to say that the discussion was "quite positive".
> There was a good deal of opposition of various kinds, much of it
> quite heated.

Why not?  None of the 11 mails was really negative.

Ansgar

Bug#839046: debootstrap: enable --merged-usr by default

[Guillem Jover]

On Mon, 2018-02-05 at 22:32:05 +, Holger Levsen wrote:
> On Mon, Feb 05, 2018 at 08:19:33PM +0100, Julien Cristau wrote:
> > On Sat, Feb  3, 2018 at 09:16:40 +0100, Marco d'Itri wrote:
> > > On Dec 23, md wrote:
> > > > On Dec 20, Julien Cristau  wrote:
> > > > > > This change was reverted in 1.0.87 as dpkg-shlibdeps didn't cope
> > > > > > properly with a merged-usr system. Thus reopening this bug report 
> > > > > > for
> > > > > > that version.
> > > > > > 
> > > > > > The dpkg-shlibdeps bugs has been fixed [1] in the mean time. So it 
> > > > > > would
> > > > > > be great if this bug report could be re-considered.

> > > > > That'll be after stretch now.

> > > > Stretch was been released long ago: please re-enable --merged-usr in 
> > > > debootstrap.

> > > There has not been any negative feedback, can we move on please?

> > Is there buy-in from the dpkg maintainer?

As I've mentioned in the past, I think the usrmerge filesystem layout
has merit and can solve some issues, and to state it very clearly, I
have no technical issue with it *what*so*ever*. But the same can be
said about the non-usrmerge layout with multiple mount-points, which
while not general anymore in Debian, can still be used perfectly fine
on controlled subsets of packages and custom built kernels w/o reliance
on an initramfs.

What I still find to be terrible is the way it's been tried to be
deployed in Debian, via the usrmerge package, which does not support
reverting the change (#848626), for which there's (AFAIK) no way to
select not using this irreversible hack from d-i, which breaks
dpkg-query --search (at least #848622 and #858331). This seems like
a nice PoV for people to play with it, in the same way local admins
can use, to some extent, symlinks to redirect subtrees to other mount
points, but I don't see how this can be seen as a production-ready
solution shipped by default, TBH.

In any case, I looked the other day into implementing the
--map-pathname option for dpkg-query, and I've got most of the code
ready. The problem is that this requires adding support for config
files and config fragments to dpkg-query, which has the additional
problem of making it possible to mess with the --showformat option
and breaking the expectations from maintscripts, for example. The
other problem is with the search behavior changing depending on the
packages providing those mappings being installed (because dpkg would
certainly not provide them).


So I'll eventually try to find a solution for the dpkg-query issue,
because it's a long-standing paper-cut in dpkg for local admins. But
I'd not be very amused if this hack is enabled by default again and
suddenly RC bugs start popping up in dpkg again, and people start
pressuring with RCness to get those fixed again because well, it's
obviously breaking people's systems…


Thanks,
Guillem

Bug#839046: debootstrap: enable --merged-usr by default

[Philipp Kern]

On 02/11/2018 02:40 PM, Philip Hands wrote:
> That being the case, I think we should let the people volunteering to do
> the work to get on with it without delay. That way there will be plenty
> of time to address any real downsides that might be revealed.

Something I did notice yesterday by accident is that ldd points to
libraries being loaded from /lib. Which is fine except that then you
can't put them into dpkg -S because dpkg does not know about the
aliasing that happens here. I suppose this is because /lib/* is listed
before /usr/lib/* in /etc/ld.so.conf.d/*-linux-gnu.conf. I suppose if
one wants to use the output to find the packages associated, one needs
to roundtrip through realpath once. But then again you might miss files
actually installed by dpkg into /lib.

So I think the question of "is there buy-in from the dpkg maintainers to
support the outcome" is not a bad one. ;-)

Kind regards
Philipp Kern



signature.asc
Description: OpenPGP digital signature

Bug#839046: debootstrap: enable --merged-usr by default

[Philip Hands]

Hi Ian,

You're not citing any concrete examples of things that will supposedly
break.

AFAICS the closest you got was:

On Sat, 10 Feb 2018, Ian Jackson  wrote:
> Another bad consequence is that some existing configurations that do
> not, for whatever reason, mount /usr early, will be harder to set up.

Which might be a fair point, except that late mounting of /usr became
explicitly unsupported with the release of Stretch:

  
https://www.debian.org/releases/stretch/armel/release-notes/ch-information.en.html#late-mounting-usr

The adoption of usrmerge was blocked before on the basis that it was too
late in the release cycle.  We are now fairly early in the release cycle.

That being the case, I think we should let the people volunteering to do
the work to get on with it without delay. That way there will be plenty
of time to address any real downsides that might be revealed.

Cheers, Phil.

P.S. I've not even installed usrmerge on any systems as yet, so please
don't assume that I'm a rabid supporter of this effort -- it just seems
entirely sane to me, whereas the pushback you pointed at ... not so much.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#839046: debootstrap: enable --merged-usr by default

[Ian Jackson]

I had a conversation with Marco about this at FOSDEM.  I'm sorry to
say that I still don't understand why we would make this change.

The links provided do not explain what the benefits are.  And there
are downsides.

One obvious downside is reduced testing of existing systems which have
filesystem layouts not easily compatible with "merged /usr" (or at
least, not compatible without wholesale moving of stuff about, which
seems like a risk which would need a substantial justification).

Another bad consequence is that some existing configurations that do
not, for whatever reason, mount /usr early, will be harder to set up.
One may argue (as Russ cogently does) that the distinction between
/usr and / cannot be coherently maintained as a distro-wide property
of software if we take into account all the realistic use cases.  But
there are some traditional configurations where the distinction _can_
be maintained and we shouldn't break those things without a reason.

Also, I fear that unless we provide a straightforward way to retain
separate /usr, including an appropriate d-i command line option, we
will get further pushback and anger from traditionalists.  We risk
reopening old wounds (see some of the less temperate responses earlier
in the thread Ansgar links to as [1]).  If there are benefits of
changing the default arrangement of new installs, it would be worth
thinking how those benefits could be obtained without the damage to
our community (even if the objections are felt, by many people, to be
technically unsound).

Finally, I have to say that I think that this summary from Ansgar
is not really accurate:

> As mentioned earlier, I would like to see --merged-usr enabled by
> default for Debian Stretch.  The last discussion on -devel@[1] was
> quite positive; I had some additional positive feedback on IRC.
...
> [1] 

That is a link to a message from Russ which mostly explains why
mounting /usr early (ie in the initramfs, by default) is a good idea.
That has now been implemented and has caused very little push-back.

But this bug report requests something entirely different: it is about
actually moving the contents of /bin into /usr/bin, etc.

It is also not fair to say that the discussion was "quite positive".
There was a good deal of opposition of various kinds, much of it
quite heated.

Thanks for your attention,
Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#839046: debootstrap: enable --merged-usr by default

[Holger Levsen]

On Mon, Feb 05, 2018 at 08:19:33PM +0100, Julien Cristau wrote:
> On Sat, Feb  3, 2018 at 09:16:40 +0100, Marco d'Itri wrote:
> > On Dec 23, md wrote:
> > > On Dec 20, Julien Cristau  wrote:
> > > > > This change was reverted in 1.0.87 as dpkg-shlibdeps didn't cope
> > > > > properly with a merged-usr system. Thus reopening this bug report for
> > > > > that version.
> > > > > 
> > > > > The dpkg-shlibdeps bugs has been fixed [1] in the mean time. So it 
> > > > > would
> > > > > be great if this bug report could be re-considered.
> > > > That'll be after stretch now.
> > > Stretch was been released long ago: please re-enable --merged-usr in 
> > > debootstrap.
> > There has not been any negative feedback, can we move on please?
> Is there buy-in from the dpkg maintainer?

cc:ing them.


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#839046: debootstrap: enable --merged-usr by default

[Julien Cristau]

On Sat, Feb  3, 2018 at 09:16:40 +0100, Marco d'Itri wrote:

> On Dec 23, md wrote:
> 
> > On Dec 20, Julien Cristau  wrote:
> > 
> > > > This change was reverted in 1.0.87 as dpkg-shlibdeps didn't cope
> > > > properly with a merged-usr system. Thus reopening this bug report for
> > > > that version.
> > > > 
> > > > The dpkg-shlibdeps bugs has been fixed [1] in the mean time. So it would
> > > > be great if this bug report could be re-considered.
> > > That'll be after stretch now.
> > Stretch was been released long ago: please re-enable --merged-usr in 
> > debootstrap.
> There has not been any negative feedback, can we move on please?

Is there buy-in from the dpkg maintainer?

Cheers,
Julien

Bug#839046: debootstrap: enable --merged-usr by default

[Marco d'Itri]

On Dec 23, md wrote:

> On Dec 20, Julien Cristau  wrote:
> 
> > > This change was reverted in 1.0.87 as dpkg-shlibdeps didn't cope
> > > properly with a merged-usr system. Thus reopening this bug report for
> > > that version.
> > > 
> > > The dpkg-shlibdeps bugs has been fixed [1] in the mean time. So it would
> > > be great if this bug report could be re-considered.
> > That'll be after stretch now.
> Stretch was been released long ago: please re-enable --merged-usr in 
> debootstrap.
There has not been any negative feedback, can we move on please?
If anybody wants to discuss this in person I will be at FOSDEM.

-- 
ciao,
Marco

Bug#839046: debootstrap: enable --merged-usr by default

[Marco d'Itri]

On Dec 20, Julien Cristau  wrote:

> > This change was reverted in 1.0.87 as dpkg-shlibdeps didn't cope
> > properly with a merged-usr system. Thus reopening this bug report for
> > that version.
> > 
> > The dpkg-shlibdeps bugs has been fixed [1] in the mean time. So it would
> > be great if this bug report could be re-considered.
> That'll be after stretch now.
Stretch was been released long ago: please re-enable --merged-usr in 
debootstrap.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#839046: debootstrap: enable --merged-usr by default

[Michael Biebl]

Hi Julien

On Tue, 20 Dec 2016 10:56:19 +0100 Michael Biebl  wrote:
> Am 20.12.2016 um 09:21 schrieb Julien Cristau:
> > On 12/20/2016 01:35 AM, Michael Biebl wrote:
> 
> >> The dpkg-shlibdeps bugs has been fixed [1] in the mean time. So it would
> >> be great if this bug report could be re-considered.
> >>
> > That'll be after stretch now.
> 
> I can understand your decision even if it makes me a bit sad that this
> feature didn't make it in time.
> 
> That said, it would be great if this change can be merged as soon as
> buster is open for development.

We are very early in the buster development cycle so it would be great
opportunity to give this another try.

Are you ok with applying Ansgar's  patch again?

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#839046: debootstrap: enable --merged-usr by default

[Michael Biebl]

Am 20.12.2016 um 10:56 schrieb Michael Biebl:
> Am 20.12.2016 um 09:21 schrieb Julien Cristau:
>> On 12/20/2016 01:35 AM, Michael Biebl wrote:
> 
>>> The dpkg-shlibdeps bugs has been fixed [1] in the mean time. So it would
>>> be great if this bug report could be re-considered.
>>>
>> That'll be after stretch now.
> 
> I can understand your decision even if it makes me a bit sad that this
> feature didn't make it in time.

To make it clear, with "this feature", I didn't mean this particular bug
report or the dpkg-shlibdeps bug report, but the merged-usr feature itself.
Just wanted to clarify in order to to avoid any misunderstanding.

Cheers,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#839046: debootstrap: enable --merged-usr by default

[Michael Biebl]

Am 20.12.2016 um 09:21 schrieb Julien Cristau:
> On 12/20/2016 01:35 AM, Michael Biebl wrote:

>> The dpkg-shlibdeps bugs has been fixed [1] in the mean time. So it would
>> be great if this bug report could be re-considered.
>>
> That'll be after stretch now.

I can understand your decision even if it makes me a bit sad that this
feature didn't make it in time.

That said, it would be great if this change can be merged as soon as
buster is open for development.

Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#839046: debootstrap: enable --merged-usr by default

[Julien Cristau]

On 12/20/2016 01:35 AM, Michael Biebl wrote:
> Control: found -1 1.0.87
> 
> Hi there!
> 
> On Wed, 28 Sep 2016 08:47:21 +0200 Ansgar Burchardt 
> wrote:
>> Package: debootstrap
>> Version: 1.0.83
>>
>> As mentioned earlier, I would like to see --merged-usr enabled by
>> default for Debian Stretch.  The last discussion on -devel@[1] was quite
>> positive; I had some additional positive feedback on IRC.
>>
>> I'm not aware of any regressions so far, except for having forgotten to
>> add "jessie-kfreebsd" to the blacklist (a list of older releases that
>> don't support merged-/usr) and debootstrap 1.0.83 failing to bootstrap
>> squeeze[2].  Both are fixed in my changes targeted at 1.0.84[3].
>>
>> So I would like to switch the default in debootstrap sooner rather than
>> later to give time to find some more bugs.  With this change, the
>> currently known bugs[4] should also be raised to "serious", but I don't
>> think any of them should be a blocker.
>>
>> Ansgar
>>
>>   [1] 
>>   [2] 
>>   [3] 
>>   [4] 
>> 
> 
> 
> This change was reverted in 1.0.87 as dpkg-shlibdeps didn't cope
> properly with a merged-usr system. Thus reopening this bug report for
> that version.
> 
> The dpkg-shlibdeps bugs has been fixed [1] in the mean time. So it would
> be great if this bug report could be re-considered.
> 
That'll be after stretch now.

Cheers,
Julien

Bug#839046: debootstrap: enable --merged-usr by default

[Michael Biebl]

Control: found -1 1.0.87

Hi there!

On Wed, 28 Sep 2016 08:47:21 +0200 Ansgar Burchardt 
wrote:
> Package: debootstrap
> Version: 1.0.83
> 
> As mentioned earlier, I would like to see --merged-usr enabled by
> default for Debian Stretch.  The last discussion on -devel@[1] was quite
> positive; I had some additional positive feedback on IRC.
> 
> I'm not aware of any regressions so far, except for having forgotten to
> add "jessie-kfreebsd" to the blacklist (a list of older releases that
> don't support merged-/usr) and debootstrap 1.0.83 failing to bootstrap
> squeeze[2].  Both are fixed in my changes targeted at 1.0.84[3].
> 
> So I would like to switch the default in debootstrap sooner rather than
> later to give time to find some more bugs.  With this change, the
> currently known bugs[4] should also be raised to "serious", but I don't
> think any of them should be a blocker.
> 
> Ansgar
> 
>   [1] 
>   [2] 
>   [3] 
>   [4] 
> 


This change was reverted in 1.0.87 as dpkg-shlibdeps didn't cope
properly with a merged-usr system. Thus reopening this bug report for
that version.

The dpkg-shlibdeps bugs has been fixed [1] in the mean time. So it would
be great if this bug report could be re-considered.

Regards,
Michael


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843073

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#839046: debootstrap: enable --merged-usr by default

[Ansgar Burchardt]

Package: debootstrap
Version: 1.0.83

As mentioned earlier, I would like to see --merged-usr enabled by
default for Debian Stretch.  The last discussion on -devel@[1] was quite
positive; I had some additional positive feedback on IRC.

I'm not aware of any regressions so far, except for having forgotten to
add "jessie-kfreebsd" to the blacklist (a list of older releases that
don't support merged-/usr) and debootstrap 1.0.83 failing to bootstrap
squeeze[2].  Both are fixed in my changes targeted at 1.0.84[3].

So I would like to switch the default in debootstrap sooner rather than
later to give time to find some more bugs.  With this change, the
currently known bugs[4] should also be raised to "serious", but I don't
think any of them should be a blocker.

Ansgar

  [1] 
  [2] 
  [3] 
  [4]