Raphael Hertzog <hert...@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
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87fwehcmkn.fsf@frosties.localnet
