Am Fr., 23. Nov. 2018 um 14:47 Uhr schrieb Stephan Seitz
<stse+deb...@fsing.rootsland.net>:
>
> On Fr, Nov 23, 2018 at 02:04:05 +0100, Matthias Klumpp wrote:
> >If there are actual issues encountered, we can always revert a change
>
> And how do you revert this change? As far as I have understand you can’t
> remove the usrmerge package and have your system in the old state again.
You don't - it's unstable, for testing these things. If it breaks, you
file a bug and fix the system.
> As others in the thread have mentioned they don’t see the risk with new
> installations but with old systems with different admins and third-party
> software.
>
> >anyway. During distribution upgrades there is a lot that can be wrong
> >and a lot of stuff the administrator needs to care about (config file
>
> Right, and it means he has enough to do and doesn’t want to debug the
> usrmerge. I don’t want to have a usrmerge at a dist-upgrade. You don’t
> really know the sequence of the package updates. I think the risk is too
> big to have a partial upgraded system.
For the sequence of installations, the APT maintainers can shed light
on what the proper plan could be to ensure the usrmerge update happens
at the right time.
> >with information to the system administrator on what to do in case of
> >an error, and works for 98% of all users anyway, I see no reason not
>
> If the update of 2% of our systems won’t work because of failing usrmerge
> I would be asked if Debian is the right distribution.
There are always unforseen issues to be expected when upgrading. And
at the moment, the only issues that are known when installing the
usrmerge package is when there are different binaries with the same
name in /bin and /usr/bin (or /sbin), and I really don't think that
this is actually a likely scenario.
For these cases though maybe the usrmerge script could ask the admin
on what to do to handle these particular binaries, instead of failing.
I am not strongly advocating for going down this route and actually
migrating all systems on update, but I do not want us to dismiss that
option because we are scared that something might go wrong without
actually knowing that there are unfixable cases where the update might
inevitably break on older installations. Instead, I would rather want
to try out the migration on a bigger scale - potentially and
temporarily break unstable (with a warning, of course), instead of
discussing over and over again potential issues that might not
actually be real and delaying a useful change because of that.
(TBH, for the buster release not switching the buildds to usrmerge and
keep debootstrap/the installer to install in an usrmerged
configuration and then do the final switch during bullseye seems
sensible and I don't see any issue this would cause. Of course if the
reproducible-builds test turns out that we only need to fix a small
amount of packages to make the usrmerge happen on buildds as well,
switching them as well could make sense still)
Cheers,
Matthias
--
I welcome VSRE emails. See http://vsre.info/
