Re: Multiarch file overlap summary and proposal
Guillem Jover <guillem@debian.org> writes:
> 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.
That is not an argument for or against refcounting. If at all it would
be marginally for refcounting:
The same situation would occur with libfoo0:i386 1.0, libfoo0:amd64 4.0
and libfoo0-common:all 2.0. But now even worse because you have 3
versions that can be out-of-sync.
Actualy if the file is shipped in the package then ref counting would
automatically detect the difference in contents and fail to install the
new libfoo0:amd64 4.0. And if the file is not shipped in the package
then ref counting has no effect on it. Again ref counting comes out
better.
Ref counting would catch some of those cases but not all and it never
makes it worse. What solves this problem is the same version requirement
or simply adding Breaks: libfoo0 (<< 4.0~) to libfoo0:* 4.0. The only
point you've made is that ref counting isn't a magic bullet that brings
us world peace.
MfG
Goswin
Reply to: