Re: Multiarch file overlap summary and proposal
Guillem Jover <firstname.lastname@example.org> writes:
> On Thu, 2012-02-16 at 10:43:53 -0800, Russ Allbery wrote:
>> I was thinking more about this, and I was finally able to put a finger
>> on why I don't like package splitting as a solution.
>> We know from prior experience with splitting packages for large
>> arch-independent data that one of the more common mistakes that we'll
>> make is to move the wrong files: to put into the arch-independent
>> package a file that's actually arch-dependent.
> This was brought up by Steve in the thread, my reply:
Thanks for the pointer, Guillem, but I'm afraid I don't think this reply
addresses my concerns. See the specific enumeration of things that we
would have to split, and the ways in which they can break. I think the
issue with C headers is particularly severe.
I don't think this mirrors an existing problem. The sorts of things we
split into arch: all packages are nowhere near as intrusive or as tightly
coupled as the things we're talking about splitting to avoid refcounting;
for example, right now, splitting out C headers into arch: all packages is
very rare. The sort of package splitting that we would do to avoid
refcounting would run a serious risk of introducing substantial new
problems that we don't currently have.
The situation with refcounting seems much less fragile than the situation
without refcounting to me. Refcounting puts the chance of error in the
right place (on people who want to use the new feature, since the
situation will not change for users who continue using packages the way
they do today), provides a clear error message rather than silent
corruption, and fails safely (on any inconsistency) rather than appearing
to succeed in situations that are not consistent. Those are all good
design principles to have.
I think the principle of not changing things for people who are not using
multiarch is particularly important, and is inconsistent with either
package splitting or with moving files into arch-qualified paths. We
should attempt to adopt new features in a way that puts most of the risk
on the people who are making use of the new features, and tries to be as
safe as possible for existing users. I agree that we should not pursue
that to an extreme that leads to an unmaintainable system, but I don't
believe refcounting has that problem.
Russ Allbery (email@example.com) <http://www.eyrie.org/~eagle/>