Re: Bug#914897: debootstrap, buster: Please disabled merged /usr by default

Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Bug#914897: debootstrap, buster: Please disabled merged /usr by default

Ian Jackson-2
Control: reassign -1 tech-ctte

Dear Technical Committee.  I don't know if you are all aware of the
discussion surrounding this, so I will recap:

Recently debootstrap was changed to do merged-/usr by default, so that
/bin -> /usr/bin etc.

It was discovered that when this change took effect on the Debian
buildds, the buildds started to build packages which do not work on
non-merged-/usr systems.

This is a special case of a general problem: buster systems with
merged-/usr sometimes build packages which are broken on
non-merged-/usr systems.

Some people have suggested that this should be fixed by making
merged-/usr mandatory for buster.  However, there is no transition
plan for this as yet and I don't think Debian is ready to commit to do
that.

So I believe that this change should be immediately reverted in sid
and buster, so that we do not prejudge the situation by increasing the
number of buster installs in the field which generate packages which
are broken on non-merged-/usr systemss.

I filed this bug against debootstrap but its maintainers do not agree:

Julien Cristau writes ("Re: Bug#914897: debootstrap, buster: Please disabled merged /usr by default"):
> We already have a change queued to revert it for build chroots.  I don't
> believe anything more is warranted at this stage.

Obviously I disagree.  I think the question is urgent.  Please would
you rapidly overrule the debootstrap maintainers.

After we have ceased introducing new lossage we can have a proper
conversation about what the plan ought to be for buster and bullseye.

Ian.

--
Ian Jackson <[hidden email]>   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.

Reply | Threaded
Open this post in threaded view
|

Processed: Re: Bug#914897: debootstrap, buster: Please disabled merged /usr by default

Debian Bug Tracking System
Processing control commands:

> reassign -1 tech-ctte
Bug #914897 [debootstrap] debootstrap, buster: Please disabled merged /usr by default
Bug reassigned from package 'debootstrap' to 'tech-ctte'.
Ignoring request to alter found versions of bug #914897 to the same values previously set
Ignoring request to alter fixed versions of bug #914897 to the same values previously set

--
914897: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914897
Debian Bug Tracking System
Contact [hidden email] with problems

Reply | Threaded
Open this post in threaded view
|

Re: Bug#914897: debootstrap, buster: Please disabled merged /usr by default

Julien Cristau-6
In reply to this post by Ian Jackson-2
On 11/28/18 2:49 PM, Ian Jackson wrote:

> Recently debootstrap was changed to do merged-/usr by default, so that
> /bin -> /usr/bin etc.
>
> It was discovered that when this change took effect on the Debian
> buildds, the buildds started to build packages which do not work on
> non-merged-/usr systems.
>
> This is a special case of a general problem: buster systems with
> merged-/usr sometimes build packages which are broken on
> non-merged-/usr systems.
>
> Some people have suggested that this should be fixed by making
> merged-/usr mandatory for buster.  However, there is no transition
> plan for this as yet and I don't think Debian is ready to commit to do
> that.
>
I'd suggest that this should be fixed by not shipping any packages that
aren't built on buildds.

Cheers,
Julien

Reply | Threaded
Open this post in threaded view
|

Re: Bug#914897: debootstrap, buster: Please disabled merged /usr by default

Ian Jackson-2
Julien Cristau writes ("Re: Bug#914897: debootstrap, buster: Please disabled merged /usr by default"):
> On 11/28/18 2:49 PM, Ian Jackson wrote:
> > This is a special case of a general problem: buster systems with
> > merged-/usr sometimes build packages which are broken on
...
> I'd suggest that this should be fixed by not shipping any packages that
> aren't built on buildds.

It would be quite a radical departure for Debian to no longer support
"I built this package for my mate to install on their computer".

Ian.

--
Ian Jackson <[hidden email]>   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.

Reply | Threaded
Open this post in threaded view
|

Re: Bug#914897: debootstrap, buster: Please disabled merged /usr by default

Julien Cristau-6
On 11/28/18 4:14 PM, Ian Jackson wrote:

> Julien Cristau writes ("Re: Bug#914897: debootstrap, buster: Please disabled merged /usr by default"):
>> On 11/28/18 2:49 PM, Ian Jackson wrote:
>>> This is a special case of a general problem: buster systems with
>>> merged-/usr sometimes build packages which are broken on
> ...
>> I'd suggest that this should be fixed by not shipping any packages that
>> aren't built on buildds.
>
> It would be quite a radical departure for Debian to no longer support
> "I built this package for my mate to install on their computer".
>
It'll be just as "supported" as it is today (which is to say, basically
not at all).  Likely to work in many cases, but also likely to explode
in a million pieces depending on the build environment.  I'd just like
to stop inflicting this risk on people downloading debs from *.debian.org.

Cheers,
Julien

Reply | Threaded
Open this post in threaded view
|

Re: Bug#914897: debootstrap, buster: Please disabled merged /usr by default

Wouter Verhelst
In reply to this post by Ian Jackson-2
On Wed, Nov 28, 2018 at 01:49:45PM +0000, Ian Jackson wrote:

> Control: reassign -1 tech-ctte
>
> Dear Technical Committee.  I don't know if you are all aware of the
> discussion surrounding this, so I will recap:
>
> Recently debootstrap was changed to do merged-/usr by default, so that
> /bin -> /usr/bin etc.
>
> It was discovered that when this change took effect on the Debian
> buildds, the buildds started to build packages which do not work on
> non-merged-/usr systems.
>
> This is a special case of a general problem: buster systems with
> merged-/usr sometimes build packages which are broken on
> non-merged-/usr systems.
>
> Some people have suggested that this should be fixed by making
> merged-/usr mandatory for buster.  However, there is no transition
> plan for this as yet and I don't think Debian is ready to commit to do
> that.
>
> So I believe that this change should be immediately reverted in sid
> and buster, so that we do not prejudge the situation by increasing the
> number of buster installs in the field which generate packages which
> are broken on non-merged-/usr systemss.

One thing that has not been answered yet in this discussion (and if the
TC is to make a decision about it, I think it should be) is "why are we
doing this". That is, what is the problem that usrmerge is meant to
solve, and how does it attempt to solve it? As far as I know, the reason
usrmerge exists is so that no files will be installed in /bin anymore;
but that seems like an XY problem.

Also, I would like to ask why the traditional solution in Debian -- make
a policy change that says no package can ship anything in /bin except
for a compatibility symlink, and make that rule RC at some point in the
future -- is not being considered. That seems like a solution that would
cause far less pain than what we're going through right now.

--
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Reply | Threaded
Open this post in threaded view
|

Re: Bug#914897: debootstrap, buster: Please disabled merged /usr by default

Marco d'Itri
On Dec 02, Wouter Verhelst <[hidden email]> wrote:

> One thing that has not been answered yet in this discussion (and if the
> TC is to make a decision about it, I think it should be) is "why are we
> doing this". That is, what is the problem that usrmerge is meant to
> solve, and how does it attempt to solve it? As far as I know, the reason
> usrmerge exists is so that no files will be installed in /bin anymore;
> but that seems like an XY problem.
https://lists.debian.org/20181121140542.GA31273@...

> Also, I would like to ask why the traditional solution in Debian -- make
> a policy change that says no package can ship anything in /bin except
> for a compatibility symlink, and make that rule RC at some point in the
> future -- is not being considered. That seems like a solution that would
> cause far less pain than what we're going through right now.
This is not a solution. For a start it would take many years.
Even ignoring that, it would not bring any improvement over the current
plan: even if your idea were executed perfectly and quickly then the
conversion program would still be in the same exact situation as it is
now: either everything in /bin/, /sbin and /lib (and its own
subdirectories) was created by the packaging system, and then we already
know that it can be converted automatically, or it was not, and then we
know that there are a few cases when the local administrator has to
decide what to do about things that were installed by himself in the
past in the wrong place.
So this would make the transition unacceptably slow while providing no
benefit at all, but it would also cost a huge amount of work to change
many packages.

--
ciao,
Marco

signature.asc (673 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bug#914897: debootstrap, buster: Please disabled merged /usr by default

Wouter Verhelst-5
On Sun, Dec 02, 2018 at 11:31:13PM +0100, Marco d'Itri wrote:
> On Dec 02, Wouter Verhelst <[hidden email]> wrote:
>
> > One thing that has not been answered yet in this discussion (and if the
> > TC is to make a decision about it, I think it should be) is "why are we
> > doing this". That is, what is the problem that usrmerge is meant to
> > solve, and how does it attempt to solve it? As far as I know, the reason
> > usrmerge exists is so that no files will be installed in /bin anymore;
> > but that seems like an XY problem.
> https://lists.debian.org/20181121140542.GA31273@...

Thanks; somehow I missed that, sorry.

> > Also, I would like to ask why the traditional solution in Debian -- make
> > a policy change that says no package can ship anything in /bin except
> > for a compatibility symlink, and make that rule RC at some point in the
> > future -- is not being considered. That seems like a solution that would
> > cause far less pain than what we're going through right now.
> This is not a solution. For a start it would take many years.

The fact that doing something in one particular way takes longer does
not in and of itself make it a bad solution.

It also need not take that long. We can declare *right now* that
shipping something in /bin (as opposed to /usr/bin) that is not a
compatibility symlink will be RC in bullseye. This would be plenty of
time for maintainers to be aware of it and to start looking at updating
their packages. With your usrmerge package, it's not at all clear to me
when the migration would be finished.

> Even ignoring that, it would not bring any improvement over the current
> plan:

This is incorrect. The current plan has some systems be merged-/usr and
others not while we are in the transition. It therefore introduces
Debian-wide complexity in that maintainers are expected to support both
merged and unmerged /usr, which causes problems (as we see here). It
also effects a change without the maintainers of the software in
question being involved, which could have unintended side effects with
some packages that we don't know yet (and that we probably won't know
about until the release of buster).

Changing this through a policy change, as we've always done, would not
have those problems:

- Maintainers are expected to move their own package to merged-/usr, so
  they would be aware of issues that might ensue and would be able to
  deal with them.
- We are not expected to be supporting merged-/usr and unmerged-/usr at
  the same time; instead, we'll be gradually moving towards a
  merged-/usr situation.
- We don't end up with packages' files being moved from under them.

> even if your idea were executed perfectly and quickly then the
> conversion program would still be in the same exact situation as it is
> now:

Yes, obviously, that's the whole point.

[...]
> So this would make the transition unacceptably slow while providing no
> benefit at all,

I don't agree with both these statements.

> but it would also cost a huge amount of work to change many packages.

Yes, and at the same time it would reduce a huge amount of *different*
work, since packages now won't need to be changed so that "being built
on merged-/usr" won't result in packages that don't build on
unmerged-/usr.

--
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Reply | Threaded
Open this post in threaded view
|

Re: Bug#914897: debootstrap, buster: Please disabled merged /usr by default

wookey-4
On 2018-12-03 00:37 +0100, Wouter Verhelst wrote:

> This is incorrect. The current plan has some systems be merged-/usr and
> others not while we are in the transition. It therefore introduces
> Debian-wide complexity in that maintainers are expected to support both
> merged and unmerged /usr, which causes problems (as we see here). It
> also effects a change without the maintainers of the software in
> question being involved, which could have unintended side effects with
> some packages that we don't know yet (and that we probably won't know
> about until the release of buster).
>
> Changing this through a policy change, as we've always done, would not
> have those problems:
>
> - Maintainers are expected to move their own package to merged-/usr, so
>   they would be aware of issues that might ensue and would be able to
>   deal with them.
> - We are not expected to be supporting merged-/usr and unmerged-/usr at
>   the same time; instead, we'll be gradually moving towards a
>   merged-/usr situation.
> - We don't end up with packages' files being moved from under them.
I don't want to add pile of verbiage here, but I'd just like to say
that everything Wouter said makes a whole lot of sense to me.

We know how to do this sort of transition, and yes it takes some time,
but that's OK. Using usrmerge to try and shortcut this, producing the
awkward 'dual-state' issues does not seem to me to be a good way to go.

Wookey
--
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/

signature.asc (849 bytes) Download Attachment