Re: Multiarch file overlap summary and proposal
On Wed, 2012-02-15 at 16:32:38 -0800, Russ Allbery wrote:
> Guillem Jover <guillem@debian.org> writes:
> > If packages have to be split anyway to cope with the other cases, then
> > the number of new packages which might not be needed otherwise will be
> > even smaller than the predicted amount, at which point it makes even
> > less sense to support refcnt'ing.
>
> I don't think the package count is really the interesting metric here,
> unless the number of introduced packages is very large (see below about
> -dev packages). I'm more concerned with maintainer time and with
> dependency complexity, and with the known problems that we introduce
> whenever we take tightly-coupled files and separate them into independent
> packages.
Well, people have been using the amount of packages as a metric, I've
just been trying to counter it. It also in a way represents the amount
of work needed.
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.
> I just posted separately about version lockstep: I think this is a
> feature, not a bug, in our multiarch implementation. I think this is the
> direction we *should* go, because it reduces the overall complexity of the
> system. [...]
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
previously.
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.
regards,
guillem
Reply to: