Steve Langasek <vor...@debian.org> writes: > On Mon, Jun 29, 2009 at 09:50:01PM +0200, Goswin von Brederlow wrote: >> Raphael Hertzog <hert...@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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org