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)
But then the proper answer is for the maintainer to put
a tight dependency “Depends: libfoo-data (= ${source:Version})”.
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?
> >* binNMUs need to be performed in lockstep for *all*
> >architectures, because the installed versions need to match.
> >↓
> >Causing useless buildd usage and user downloads for arches not
> >affected. “Fixing” this by making dpkg treat binNMU versions
> >specially, besides being just another special case needed for
> >M-A:same packages,
>
> What do you mean by “another”? Yes, MA:same packages needs special
> treatment, because they _are_ special.
To some extent... in any case I agree that we should at some point do
something to allow bin-nmu of packages on some arches only and also to
allow co-installation of packages with versions differing only by their
binnmu number (this could be easily fixed by using version of the source
package intead of binary version).
I'm not convinced that Guillem's answer is the right one though. Your
suggestion below seams appealing too.
> http://lists.debian.org/debian-devel/2012/02/msg00316.html
Quoting you:
Packages could simply split debian/changelog into two parts:
/u/s/d/$p/changelog(.Debian).gz - the architecture-independent part;
/u/s/d/$p/changelog.binNMU-$arch.gz - the binNMU part.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/
--
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/20120211101538.gm13...@rivendell.home.ouaza.com
