Re: ia32-libs depends on ia32-apt-get ?
Steve Langasek <vorlon@debian.org> writes:
> On Mon, Jun 29, 2009 at 09:50:01PM +0200, Goswin von Brederlow wrote:
>> Raphael Hertzog <hertzog@debian.org> writes:
>
>> > There is work going on recently. Steve Langasek drafted a plan that he
>> > wants to bring forward in Ubuntu Karmic Koala and it has been reviewed by
>> > Guillem Jover, the dpkg maintainer. Guillem also has plans to make it a
>> > reality inside Debian but I don't know of any timeframe.
>
>> > https://wiki.ubuntu.com/MultiarchSpec
>
>> They messed up some finer details, broke the existing patches,
>
> 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.
> (Nor is there one for the MultiarchSpec, but that's only because Guillem and
> I are still hammering out some of the details that we don't yet agree on; so
> a public announcement is a little bit premature.)
So you do that in a dark corner ignoring any other people that worked
on multiarch before? You are only 2 people, you only have 4 eyes (I
assume). You are bound to miss something that a larger group would
spot.
>> 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.
> release cycles, and I don't see that your ia32-apt-get kludges are doing
> anything to get us there sooner.
Please stop confusing ia32-apt-get with multiarch. It clearly is a
kludge to keep 32bit binaries working till there is multiarch. It is
not ment as a replacement.
> 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
Foo and Bar are binary packages that in some way use perl as a simple
interpreter. Libbaz-perl and libbat-perl on the other hand are
bindings for perl to use 2 C libraries libbaz and libbat.
Now with your proposal you have a few options:
1) perl has no Multi-Arch field
Eigther foo can be installed or bar. But never both.
2) perl has Multi-Arch: same
Now perl:i386 and perl:amd64 are flagged as coinstallable. Not
supported.
3) perl has Multi-Arch: foreign
Now foo and bar can be installed but so can libbaz-perl and
libbat-perl. One of the libs will be broken.
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.
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.
>> and have a broken plan for -dev packages.
>
> 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.
Actually the filesystem layout for -dev packages is no problem at
all. We already have /usr/include/$(DEB_HOST_GNU_TYPE) for include
files (where needed) and /usr/lib/$(DEB_HOST_GNU_TYPE) for the *.so
links. That part might be work but not a problem.
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):
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.
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.
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.
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.
The problem is you have no way of specifying which of the two cases
apply in the Architecture: all package, because:
| 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 something I noticed while working on a multiarch dpkg and
ia32-apt-get. I actually did run into this case with xlibs-dev.
>> Too bad they did that without involving the people already working on
>> multiarch via the alioth project.
>
> A project whose mailing list archive contains nothing but spam since 2006,
> and whose primary proponent is also the author of ia32-apt-get? Yeah, not
> really seeing how that would have been a win.
Because everything was blocked by the toolchain. Gcc only recently was
fixed to fully support /usr/lib/$(DEB_HOST_GNU_TYPE)/. There wasn't
really anything to discuss or do.
All I'm saying is that it would have been nice to drop a note on the
ML or the wiki about your intention to see if any of the old people
want to contribute too.
MfG
Goswin
Reply to: