Re: Multiarch file overlap summary and proposal
Guillem Jover <email@example.com> writes:
> About tightly-coupled files, they can cause serious issues also with
> refcounting, consider that there's always going to be a point when
> unpacking one of the new instances will have a completely different
> vesion than the other already unpacked instance(s). So packages could
> stop working for a long time if say unpacked libfoo0:i386 1.0 has
> file-format-0, but new libfoo0:amd64 4.0 has file-format-2, and the file
> didn't change name (arguably this could be considered an upstream
> problem, depending on the situation), this would be particularly
> problematic for pseudo-essential packages.
Yes, I agree. Refcounting does complicate the upgrade situation, since
you really want to upgrade all installed architectures in lockstep to
ensure that we maintain as many of the guarantees of file consistency as
we do now with single-arch upgrades.
> I've replied to that separately, in any case I think the best compromise
> would be to add version lockstep to dpkg, but not refcounting. Because
> the first is a restriction that can always be lifted if it's confirmed
> to cause issues (which I think it will), and the second can always be
> added later because it's something that allows things not permitted
I definitely understand where you're coming from, and I would be lying if
I said that introducing refcounting doesn't make me nervous. You're
right, it's something that's going to be very difficult to back out of if
we decide it's a mistake.
I do think it's the best solution to a complex set of issues, but we're
going to have to use it in conjunction with pretty tight version lockstep
to avoid problems with file inconsistency.
> But at this point it seems I'm alone in thinking that refcounting has
> more negative implications than positive ones, and I cannot get myself
> to care enough any longer to push for this. So some weeks ago I added
> back both those things to my local repo.
Well... no one likes to win an argument under those terms. I'd much
rather have us all agree. But I do want to wholeheartedly second
Christian's thanks for all your work on dpkg in the middle of a really
difficult situation, and your willingness to make compromises like this
even when you think they're the wrong technical decision. That's really
hard to do, and I think it's also very admirable.
If this all turns out to be a horrible mistake, I for one will try to help
us back out of it as needed, to put my resources where my advocacy has
Russ Allbery (firstname.lastname@example.org) <http://www.eyrie.org/~eagle/>