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/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org