Re: usrmerge -- plan B?
Michael Stone <email@example.com> writes:
> On Wed, Nov 21, 2018 at 02:19:56PM -0800, Russ Allbery wrote:
>> Doing this check in reproducible-builds definitely helps allievate my
>> concerns as a backstop, but this is still fragile and we don't have a
>> tight test/fix cycle. And, in general, I'm dubious of a path where we
>> support building a package on both merged and unmerged systems and then
>> allow running it on both merged and unmerged systems. There are so
>> many places that binary paths creep into software build processes, and
>> so many different upstream software build processes to analyze.
> I'm likewise generally dubious of a process where we try to merge two
> directories into one directory during a system upgrade as a side effect
> of installing a package. I've just seen too many strange things on real
> systems. If not supporting legacy installs isn't an option, we never
> should have started this.
I don't believe supporting legacy installs *without doing the migration*
is an option, or at least an option that we should take. We could
theoretically make it work, but the ongoing burden to packagers and to
our testing infrastructure would be high. It would be yet another obscure
and irritating thing that you'd have to mess with when packaging and that
was very hard to test, and we already have way too many of those.
So yes, this is exactly the decision before us.
Russ Allbery (firstname.lastname@example.org) <http://www.eyrie.org/~eagle/>