Re: ia32-libs depends on ia32-apt-get ?
Steve Langasek <vorlon@debian.org> writes:
> On Tue, Jun 30, 2009 at 06:52:34PM +0200, Goswin von Brederlow wrote:
>> 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?
Yes. No.
I was using perl as example because it verry nearly already is doing
this with its perlapi-5.10.0 provide.
I imagine dh_python / dh_pycentral / dh_pysupport will be able to
autodetect the need for a dependency on the python ABI automatically
as well.
>> > 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.
You really need me to go through the rdpends of interpreters and find
an example of 2 arch:any packages that depend on one? Ok, here we go:
Package: skyped
Architecture: i386
Depends: python (>= 2.5), python-gnutls, python-skype (>= 0.9.28.7)
Description: Daemon to control Skype remotely
Package: totem
Architecture: amd64
Depends: python, python-support (>= 0.90.0)
Description: A simple media player for the GNOME desktop based on GStreamer
So installing skyped would require a 32bit python and 32bit totem
prior to a release cycle.
>> 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.
See above.
>> 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.
Not just -dev metapackages, any meta/transitional packages can run
into this. xlibs-dev is just the package where I noticed the issue
first.
>> 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.
That was all I was saying.
>> 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.
Not always possible or feasable. You will probably call it another
unproven corner case but imagine an architecture all package that
depends on perl and some perl bindings for a library. The bindings
can't be Multi-Arch: foreign.
Lets see, what do we have in that regard?
An arch:all package depending on an interpreter and bindings:
angrydd, balazar, balazarbrothers, bouncy, bubbros, cappuccino,
castle-combat, ... is there any python game not falling into that
category?
ggz-kde-client -> ggz-python-games -> python-pygame
There is your corner case.
A selective recurison for an any->all->any dependencie would be
usefull I believe.
>> | 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.
It would be well defined but less powerfull/flexible.
MfG
Goswin
Reply to: