Re: ia32-libs depends on ia32-apt-get ?

[Steve Langasek <vorlon@debian.org>]

On Tue, Jun 30, 2009 at 06:52:34PM +0200, Goswin von Brederlow wrote:
> > Patches implementing what?  I don't see any public discussion of an agreed
> > design for the package manager.

> Patches for dpkg to accept the Multi-Arch field as a tristate of Yes,
> No or missing and for packages to set that field. It's been
> yes/no/missing in all the mails about multiarch for years and suddnely
> you changed the string.

Based on feedback from Guillem as dpkg maintainer (among others).  It does
no good to have a spec that's stable for years if it gains no traction with
the maintainers of the packages where it has to be implemented.

> >> made the whole thing need a full release cycle for a transition due to
> >> DEBIAN/control format changes

> > You appear to be referring to
> > <https://wiki.ubuntu.com/MultiarchSpec#Extended%20semantics%20of%20per-architecture%20package%20relationships>.
> > What do you propose as an alternative that would let us achieve multiarch
> > sooner?  Multiarch has already failed to get traction for more than two

> Look at perl for example:

> Package: perl-base
> Provides: perlapi-5.10.0

> I suggest to also provide perlabi-$(DEB_HOST_GNU_TYPE) or
> perlabi-5.10.0-$(DEB_HOST_GNU_TYPE). Perl extensions that need a
> matching ABI can then easily depend on the right package.

> The dh_perl helper could add the dependency automatically allowing a
> binNMU to transition many packages.

Do you intend to do the same for python, which has no such "API" provides?
Or are you only proposing a workaround for perl?

> > Also, what are the immediate practical use cases for cross-arch depends on
> > extensible interpreters such as python and perl?  Wine doesn't need this,
> > nor does nspluginwrapper AFAICS, so what actually is negatively impacted by
> > requiring that class of dependencies to be deferred by a release cycle?

> Say you have:

> Package: foo
> Architecture: amd64
> Depends: perl

> Package: bar
> Architecture: i386
> Depends: perl

> Package: libbaz-perl
> Architecture: amd64
> Depends: perl

> Package: libbat-perl
> Architecture: i386
> Depends: perl

This is a hypothetical.  I asked for evidence of a *practical* impact.

> 4) Using Depends: perl [same]
>    This would allos foo and bar to be both installed but only the
>    right one of libbaz-perl and libbat-perl. But that takes a release
>    cycle to introduce the new syntax.

But if it's unproven that anyone *needs* this, there's no reason to worry
about the delay for implementing this corner case.

>    Note that you also need perl to break libbaz-perl and libbat-perl
>    versions prior to the ones with "Depends: perl [same]" or yet
>    another release cycle. But a Provides: perlabi-$(DEB_HOST_GNU_TYPE)
>    suffers from the same problem.

The need for flag days for interpreters is identified as a limitation of
this design, and is actually a point that's currently under review.

> > Handling of -dev packages is defined as *out of scope* for this
> > specification.  I fail to see how it's broken to confine the initial scope
> > to those elements that impact the package management tools, to avoid getting
> > bogged down in irrelevant discussions about filesystem layouts.

> The problem is in the dependencies and actually not restricted to just
> -dev packages. Transitional/Meta packages suffer from this in
> general. For the sake of an example lets say you have the following
> packages (xlibs-dev being a real example):

You know xlibs-dev is no longer in the archive, right?

-dev metapackages don't make a whole lot of sense except on a transitional
basis.  While there may be some things that still need to be tightened up
here, if one of the outcomes is that -dev metapackages have to be made arch:
any, I don't think that's too onerous.

> Source: foo
> Build-Depends: xlibs-dev, bar

> Package: xlibs-dev
> Architecture: all
> Depends: libice-dev, libsm-dev, libx11-dev, libxext-dev, ...

> Package: libice-dev
> Architecture: any
> Multi-Arch: same

> Package: bar
> Architecture: any
> Multi-Arch: foreign
> Depends: baz

> Package: baz
> Architecture: any

> You assume:

> | Dependencies, Build-Dependencies, and Recommends within an existing
> | architecture foo will continue to remain closed over the set of
> | packages declaring either Architecture: foo or Architecture: all.

This is a statement of the implications for the archive, and is an
expression of the existing archive requirements.  It says nothing about how
build-dependency fields are to be interpreted on a build system.

> Say you are building on amd64 and libice-dev:i386, bar:i386 and
> baz:i386 is installed.

> 1) The 'Multi-Arch: foreign' breaks your assumption.
>    Bar:i386 + baz:i386 satisfy a dependency on bar for amd64 just
>    fine. You assumption would indicate you don't consider that a
>    satisfaction of the Build-Depends.

Per the above, your conclusion here is invalid.  It satisfies the
build-depends, it's just not sufficient from an archive perspective for
bar:i386 to be the *only* package in the archive that satisfies this
build-dependency; and this is not the bar that will be used by the buildds.

> 2) xlibs-dev being Architecture: all satisfies the Build-Depends
>    But libice-dev:i386 is the wrong package. Again the set is not
>    closed but this time that actualy is an error.

> What actually needs to happen in this case is that the dependencies of
> xlibs-dev need to be checked against the architecture (amd64) being
> build for. Or more general the architecture of the package requesting
> a dependency check. So on Architecture: all packages you have to
> recursively check the depends.

This points out that more attention may need to be given to how
any->all->any transitive dependencies are handled, yes.

> But not always. Say you have a package buzz that just contains a few
> bash scripts and is in the dependency chain somwhere. A bash:amd64
> should satsify for a dependency on buzz from both an amd64 package and
> i386 package.

Which is expressed by making bash Multi-Arch: foreign, truncating the
recursive architecture enforcement.

> | 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.

> If you drop that and allow Architecture: all packages to carry a
> Multi-Arch field you can say the following:

> An Architecture: all package with 'Multi-Arch: same' is only
> considered installed for a package of architecture XXX if all its
> dependencies (Depends, Conflicts, ...) are also satisfied for
> architecture XXX. Dependencies are checked recursively.

> An Architecture: all package with 'Multi-Arch: foreign' is considered
> installed for packages of any architecture.

> An Architecture: all package without Multi-Arch field could be either
> or. Recursively checking dependencies would be the safe option.
> Acepting it as 'foreign' is the more practical one but would initialy
> allow broken dependency trees.

This is also an option, but I think only transitively enforcing the
same-arch requirement for dependencies is sufficient to solve the problem
and yields a simpler outcome.

-- 
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