Re: usrmerge -- plan B?
On Thu, 2018-11-22 at 13:56 +0000, Ian Jackson wrote:
> Marco d'Itri writes ("Re: usrmerge -- plan B?"):
> > On Nov 22, Ian Jackson <ijackson@chiark.greenend.org.uk> wrote:
> > > Marco d'Itri writes ("Re: usrmerge -- plan B?"):
> > > > So far nobody reported anything significant.
> > >
> > > I hear there was a major free software project who accidentally
> > > usrmerged their build systems and discovered that they then built
> > > broken packgaes.
> >
> > And it was quickly fixed, so no big deal.
>
> I think this allows us to calibrate what you consider `anything
> significant'.
Causing problems with a few packages is not a significant problem. We
should stop upgrading GCC to newer versions otherwise as doing so
generates tons of RC bugs every time.
> There is tradeoff here between risk of breakage, and reduction of
> future work (as most clearly explained by Russ). The argument that
> is
> being made is that the risk is low because of a lack of reports of
> breakage.
Moving files around in such a matter that they are still available in
the old location (via a symlink) is not a very invasive change, so
there is only a small risk of problems. That matches what was reported
so far.
Very few changes come with zero problems.
> Others have observed that systems most likely to experience trouble
> will not have been upgraded. For example, chiark was first installed
> with Debian 0.93R5 in 1993. Obviously I haven't usrmerged it. No-
> one sensible in my position would do so.
Why should "originally installed in 1993" make moving files from one
location to another more difficult? It's not different than having to
add LSB init headers to local init scripts (or just replace them with
systemd units these days), having to purge leftover conffiles from
removed packages or similar changes on upgrades.
If the system is prone to breakage on upgrades in general, I would
expect anyone sensible to fix that.
Ansgar
Reply to: