[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Multi-arch and dependencies on arch: all packages

On Thu, Feb 10, 2011 at 05:00:13PM +0100, Raphael Hertzog wrote:
> Steve reported me this problem concerning the current implementation of
> the multiarch spec (he uses my latest pu/multiarch/snapshot/* branch).

> Le mercredi 09 févr. 2011, Steve Langasek a écrit :
> >  - I've just marked tzdata (an Architecture: all package) as Multi-Arch:
> >    foreign in the Ubuntu archive because I noticed my test libc6 package
> >    (libc6 depends on tzdata in Ubuntu but not in Debian) failed to install,
> >    listing this dependency as one of the reasons.  At first I was going to
> >    report this as a bug, but then I remembered this:
> >    https://wiki.ubuntu.com/MultiarchSpec#Dependencies%20involving%20Architecture:%20all%20packages
> > 
> >    Now dpkg fails to install this package at all, with this error:
> > 
> >  parsing file '/var/lib/dpkg/tmp.ci/control' near line 18 package 'tzdata':
> >  package has multiarch field but is architecture all
> > 
> >    And doing so complies with this requirement from the spec:
> > 
> >    "Setting the Multi-Arch field on a package which is Architecture: all is
> >    considered an error. dpkg-deb must refuse to generate a .deb with this
> >    combination of values. Behavior when trying to install such a package is
> >    undefined."
> > 
> >    (https://wiki.ubuntu.com/MultiarchSpec#Binary%20package%20control%20fields)
> > 
> >    These two requirements are clearly in conflict.  I've updated the wiki
> >    page to make it clear that only Multi-Arch: same is disallowed for
> >    Architecture: all packages.  Please update the dpkg implementation to
> >    match when you have a chance.

> I think it's wrong to (have to) add the Multi-Arch field to architecture
> all packages. I would rather suggest that we consider them as
> automatically satisfying any dependency (i.e. the Multi-Arch: foreign
> would be implicit).

> What do other people think?

> An architecture all package that provides something arch specific is
> very rare and it's often meant to be used in situation where you precisely
> want to make this available to other architectures (i.e. syslinux-common).

> So I don't think that we have to go through all the trouble to whitelist
> them one by one.

Sorry, I should have included in my mail the rationale for this requirement
- which I remembered from the drafting sessions but didn't add when updating
the wiki page.

The reason we determined while drafting that Architecture: all packages
should not automatically satisfy dependencies as if they were Multi-Arch:
foreign is that in the current scheme, an Architecture: all package can very
well be used as a metapackage to bridge a dependency between two
Architecture: any packages that need to be of the same architecture.

As a practical example: the python package is Architecture: all.  Every
python C extension package is Architecture: any and depends on python as an
/interface/ to the python2.x Architecture: any packages which *must* be of
the same architecture.

I believe the consensus when drafting was that, if we didn't treat
Architecture: all packages as being equivalent to the native arch for
dependency solving, there would be cases when we would have insufficient
information to properly verify dependencies due to the masking effect.

With that rationale, does this requirement make more sense to you?  Or do
you see some other way to make this work?  (Bearing in mind that both dpkg
and higher-level package managers like apt need to be able to sort through
the deps correctly)

Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

Attachment: signature.asc
Description: Digital signature

Reply to: