Re: Summary: dpkg shared / reference counted files and version match

[Goswin von Brederlow <goswin-v-b@web.de>]

Raphael Hertzog <hertzog@debian.org> writes:

> Hello,
>
> On Sat, 11 Feb 2012, Jakub Wilk wrote:
>> >* Deploying refcnt means that M-A:same packages must always be at
>> >the same exact installed version, so that the file contents can
>> >match.
>> >â??
>> >More difficult upgrade paths, as this ties the different arch
>> >dependency trees around M-A:same barriers.
>> 
>> By allowing co-installation of two different versions of the same
>> package, you are opening a can of worms, regardless of whether
>> refcnt is implemented or not.
>
> I'm tempted to agree but I can't come up with a good reason.
>
> The most worrying problem would be a version skew between
> 2 instances of libfoo and its common libfoo-data.
>
> It could be a source of subtle bugs if this leads to having
> libfoo:i386 (1.0) + libfoo:amd64 (2.0) + libfoo-data:all (2.0)

In that case you can already have libfoo:i386 (1.0) + libfoo-data:all
(2.0) so the problem alreadyarises on a non-multiarch system.

> But then the proper answer is for the maintainer to put
> a tight dependency â??Depends: libfoo-data (= ${source:Version})â??.

Probably better would be libfoo-data: Breaks: libfoo (<< 2.0~).

> Any other problem is nothing else than a usual dependency problem
> that would likely also be triggered in a non-multiarch world. Or am
> I missing something? Do you have examples of possible problems?

Just that your example is already covered by non-multiarch.

MfG
        Goswin