Re: Bug#914897: debootstrap, buster: Please disabled merged /usr by default
On Sun, Dec 02, 2018 at 11:31:13PM +0100, Marco d'Itri wrote: > On Dec 02, Wouter Verhelst 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.ga31...@espresso.pseudorandom.co.uk 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
Re: Bug#914897: debootstrap, buster: Please disabled merged /usr by default
On Dec 02, Wouter Verhelst 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.ga31...@espresso.pseudorandom.co.uk > 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 Description: PGP signature
Re: Bug#914897: debootstrap, buster: Please disabled merged /usr by default
On Wed, Nov 28, 2018 at 01:49:45PM +, 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
Re: Bug#914897: debootstrap, buster: Please disabled merged /usr by default
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
Re: Bug#914897: debootstrap, buster: Please disabled merged /usr by default
Hello,
On Wed, Nov 28, 2018 at 03:14:20PM +, Ian Jackson wrote:
> Julien Cristau writes ("Re: Bug#914897: debootstrap, buster: Please disabled
> merged /usr by default"):
[...]
> > 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".
For the case of locally built binaries, bringing any problem
that usrmerge would hit to the light would be preferable.
eg. Consider the case of:
cat << EOF > /usr/local/bin/grep
#!/bin/sh
grep --color $@
EOF
chmod +x /usr/local/bin/grep
(Or export PATH=$HOME/bin:$PATH and something similar as above.)
I've certainly in my maintainer history had people demand fixes
for problems that where caused by their local build environment
setup containing alot crazier things than the above.
Regards,
Andreas Henriksson
PS. As previously mentioned reproducible builds has already been set up
to help catch issues so I don't understand the urgency, see:
https://tests.reproducible-builds.org/debian/issues/unstable/paths_vary_due_to_usrmerge_issue.html
Better ask release-team for permission to treat these as RC if you feel
strongly about these issues.
Re: Bug#914897: debootstrap, buster: Please disabled merged /usr by default
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 JacksonThese 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.
Re: Bug#914897: debootstrap, buster: Please disabled merged /usr by default
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
Re: Bug#914897: debootstrap, buster: Please disabled merged /usr by default
Julien Cristau writes: > We already have a change queued to revert it for build chroots. I don't > believe anything more is warranted at this stage. Making the package behave differently on build chroots is adding a bug, not fixing one. Bjørn
Processed: Re: Bug#914897: debootstrap, buster: Please disabled merged /usr by default
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 ow...@bugs.debian.org with problems
Re: Bug#914897: debootstrap, buster: Please disabled merged /usr by default
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 JacksonThese 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#914897: debootstrap, buster: Please disabled merged /usr by default
On 11/28/18 1:07 PM, Ian Jackson wrote: > 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 > approach. > > 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. > We already have a change queued to revert it for build chroots. I don't believe anything more is warranted at this stage. > 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. > Definitely not. Cheers, Julien
Bug#914897: debootstrap, buster: Please disabled merged /usr by default
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 approach. 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. -- Ian JacksonThese 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.
