[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#914897: marked as done (tech-ctte: Should debootstrap disable merged /usr by default?)

Your message dated Tue, 05 Mar 2019 12:23:44 +0100
with message-id <[🔎] 1757030.bERFElIiIH@odyx.org>
and subject line Re: Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?
has caused the Debian Bug report #914897,
regarding tech-ctte: Should debootstrap disable merged /usr by default?
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 owner@bugs.debian.org

914897: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914897
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: debootstrap
Version: debootstrap/1.0.110
Severity: serious

Merged /usr is now the default in buster.  As discussed on
debian-devel, however, binary packages built on a merged-usr system
are not installable on a non-merged-usr system.  I think we would like
ad hoc builds of packages from one buster machine to be installable on
other buster machines.  That is not compatible with the current

This was an unanticipated problem.  The discussion on -devel has not
reached a consensus on a way forward, and there is no transition plan.

Accordingly, please revert this change for buster.

IMO this revert should be done quickly, to minimise the number of
installs which will generate broken packages.  If you do not agree
with my proposal, then I still think we should revert the change in
sid/buster while the matter is discussed.

This affects stretch-backports too, but I think it will be most
convenient to file a separate bug for that.


Ian Jackson <ijackson@chiark.greenend.org.uk>   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.

--- End Message ---
--- Begin Message ---
Le lundi, 4 mars 2019, 22.28:38 h CET Margarita Manterola a écrit :
> Hi,
> > - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> > 
> > The winners are:
> > 	 Option M `middle`
> > 	 Option H `hard`
> > 
> > - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> > 
> > Dear Marga, as Chair, could you please make use of your casting vote to
> > break this tie?
> I'm using my casting vote to vote in favor of M `middle` (i.e. consider
> that the desirable situation at the time of bullseye is that both directory
> schemes are allowed, all packages can be built on either).
> My rationale for taking this decision is as follows:
> Right now we are not ready to migrate to building on merged-usr systems in
> Debian, there are still 29 known packages that are broken and need to be
> fixed.  My expectation is that those packages will be fixed in the not so
> distant future (i.e.  before bullseye) and that after that, the buildd
> profile in debootstrap will default to having a merged /usr, so that new
> buildd chroots will use that setup.
> However, we have no control over how fast individual developers and
> derivative distributions will migrate to the new format. It's possible that
> more time will be required until everyone is ready to migrate.
> Additionally, as of our current understanding of the issue, there are no
> known problems for building on a non-merged system. Supporting this
> setup does not imply additional work from the point of view of our
> maintainers (for now).
> In the future, it would be a bug if a problem is discovered with building a
> package on a non-merged /usr system. I understand that this would mean
> additional work to the maintainers of such a package, but at least as of
> today this is a non-issue. Eventually, when fixing such bugs becomes a
> significant burden for our maintainers, it can be decided that the setup is
> no-longer supported, but my personal recommendation would be to wait at
> least until bullseye+1. That's why I'm voting "Middle" for bullseye.

I have announced this decision on debian-devel-announce:

I am therefore hereby closing this bug.

Thank you to all involved parties!


Attachment: signature.asc
Description: This is a digitally signed message part.

--- End Message ---

Reply to: