Re: Multiarch preparations needed for etch dpkg
On Sat, May 27, 2006 at 01:07:01AM +0200, Goswin von Brederlow wrote: Steve Langasek [EMAIL PROTECTED] writes: On Mon, May 22, 2006 at 10:07:00AM +0200, Goswin von Brederlow wrote: Only the dpkg:arch is required and that can be done with Provides: dpkg-arch again. Right. I wonder if even this should strictly be necessary, though, or if dpkg shouldn't be able to provide the needed features for build-essential in any architecture version... The problem is that dpkg has the default architecture hardcoded in the binary and that can't be changed without large side effects. If we allow an amd64 dpkg to behave like an i386 dpkg then I bet people will start messing things up and build i386 debs on amd64 systems and complain why they can't build amd64 debs. Keeping the architecture hardcoded in dpkg and have the architecture of the dpkg (dpkg-dev?) package decide what architecture to build for seems a simple solution. But that is just me. And I'm also to lazy to dig through dpkg source to make it provide the same behaviour for any arch. Well, since the whole reason we would need to declare a dpkg-dev:arch dependency is that dpkg-dev is *not* going to be a multiarch package, having such a dependency makes it impossible for (e.g.) build-essential:i386 and build-essential:amd64 to be co-installable, right? That seems unfortunate to me. Assuming no one comes up with a brilliant^Wcrazy plan to make dpkg-dev autoselect the default architecture based on something like the Linux personality, I would figure that the sensible thing here is to require anyone trying to build packages for a non-default arch to declare this arch using the -a option to dpkg-buildpackage. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Multiarch preparations needed for etch dpkg
Steve Langasek [EMAIL PROTECTED] writes: On Sat, May 27, 2006 at 01:07:01AM +0200, Goswin von Brederlow wrote: Steve Langasek [EMAIL PROTECTED] writes: On Mon, May 22, 2006 at 10:07:00AM +0200, Goswin von Brederlow wrote: Only the dpkg:arch is required and that can be done with Provides: dpkg-arch again. Right. I wonder if even this should strictly be necessary, though, or if dpkg shouldn't be able to provide the needed features for build-essential in any architecture version... The problem is that dpkg has the default architecture hardcoded in the binary and that can't be changed without large side effects. If we allow an amd64 dpkg to behave like an i386 dpkg then I bet people will start messing things up and build i386 debs on amd64 systems and complain why they can't build amd64 debs. Keeping the architecture hardcoded in dpkg and have the architecture of the dpkg (dpkg-dev?) package decide what architecture to build for seems a simple solution. But that is just me. And I'm also to lazy to dig through dpkg source to make it provide the same behaviour for any arch. Well, since the whole reason we would need to declare a dpkg-dev:arch dependency is that dpkg-dev is *not* going to be a multiarch package, having such a dependency makes it impossible for (e.g.) build-essential:i386 and build-essential:amd64 to be co-installable, right? That seems unfortunate to me. Yes. I don't think it would be wise to have build-essential be coinstallable for multiple archs. Note: dpkg-dev is architecture all. The dpkg package itself determines the native architecture for a system. I guess it wouldn't be too hard to add a /etc/dpkg/architectures file that sets the native architecture for building packages, the prefered architecture when installing packages and any compatible architectures allowed on the system. We already need some config option to allow/disalow architectures in case you don't want multiarch. Assuming no one comes up with a brilliant^Wcrazy plan to make dpkg-dev autoselect the default architecture based on something like the Linux personality, I would figure that the sensible thing here is to require anyone trying to build packages for a non-default arch to declare this arch using the -a option to dpkg-buildpackage. You can't set your linux personality to i386 on ppc or alpha but people wanted to use qemu to install and run i386 packages there. There is also the case of switching between glibc and uclibc that isn't reflected in the personality. This needs something more than the linux32/64 binary. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Multiarch preparations needed for etch dpkg
On Mon, May 22, 2006 at 10:07:00AM +0200, Goswin von Brederlow wrote: Goswin von Brederlow [EMAIL PROTECTED] writes: Say you have a binary package (Multi-Arch: no) firfox and a library/plugin package firefox-mplayer-plugin. This could be handled by firefox having a Provides: firefox-abiXX-arch-os-libc. Apt and perl for example already provide an abi pseudopackage. After a lengthy discussion on irc Steve and I have come to the conclusion that we don't seem to need a Depends: foo:arch syntax if we instead implement versioned provides. More precisely, you don't need Depends: foo:arch if we have a suitably scalable solution that can be implemented using Provides. I.e., versioned Provides support is only a barrier to adoption to the extent that we have packages providing plugin interfaces, for which we want to support multiarch consumers, and the plugin interfaces rev frequently. I think packages with a versioned depends on a provided package will be uninstallable with the current dpkg, right? If so that would only mean packages in etch+1 will be uninstallable without a prior update to a dpkg that handles versioned provides. Yes. Having packages that can't be installed with previous-generation package management tools should be ok, it's only having packages that are installed when they shouldn't be that really becomes a problem. Only the dpkg:arch is required and that can be done with Provides: dpkg-arch again. Right. I wonder if even this should strictly be necessary, though, or if dpkg shouldn't be able to provide the needed features for build-essential in any architecture version... So we don't have to change the syntax but we do have to change dpkg to smooth the way ahead for etch+1. Yes. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Multiarch preparations needed for etch dpkg
Steve Langasek [EMAIL PROTECTED] writes: On Mon, May 22, 2006 at 10:07:00AM +0200, Goswin von Brederlow wrote: Only the dpkg:arch is required and that can be done with Provides: dpkg-arch again. Right. I wonder if even this should strictly be necessary, though, or if dpkg shouldn't be able to provide the needed features for build-essential in any architecture version... The problem is that dpkg has the default architecture hardcoded in the binary and that can't be changed without large side effects. If we allow an amd64 dpkg to behave like an i386 dpkg then I bet people will start messing things up and build i386 debs on amd64 systems and complain why they can't build amd64 debs. Keeping the architecture hardcoded in dpkg and have the architecture of the dpkg (dpkg-dev?) package decide what architecture to build for seems a simple solution. But that is just me. And I'm also to lazy to dig through dpkg source to make it provide the same behaviour for any arch. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Multiarch preparations needed for etch dpkg
Goswin von Brederlow [EMAIL PROTECTED] writes: Steve Langasek [EMAIL PROTECTED] writes: On Sat, May 20, 2006 at 10:27:35PM +0200, Goswin von Brederlow wrote: - Allow arch specific depends I propose to use Depends: pkg:arch (= 1.2-3) as syntax for thses. While for etch no package should use them dpkg should accept them so installing etch+1 debs can go without hitch. (Note that this also impacts on apt and aptitude) Please provide a counter-example to the following assertion: A multiarch package's dependency on another package must be satisfied by a package of a particular (i.e., of the same) architecture IFF the depended-on package is also a multi-arch package. If you don't have any counter-examples to this claim, then it's my belief that the last of these changes is not required, because versioned dependencies are enough to ensure the dependency is not incorrectly satisfied by a non-multiarch version of the package, and Multi-Arch: yes flags on the new versions of the package give dpkg front-ends enough information to correctly determine whether the dependency is properly satisfied and to resolve the dependency if not. Say you have a binary package (Multi-Arch: no) firfox and a library/plugin package firefox-mplayer-plugin. This could be handled by firefox having a Provides: firefox-abiXX-arch-os-libc. Apt and perl for example already provide an abi pseudopackage. After a lengthy discussion on irc Steve and I have come to the conclusion that we don't seem to need a Depends: foo:arch syntax if we instead implement versioned provides. Afaik currently dpkg allows Provides: foo (= 1.0) but the version gets ignored when resolving depends. If we change the semantics so that version now have meaning an older dpkg will still ignore it and potentialy install the wrong package. But it won't stop people from updating to a newer dpkg and frontends, which then in turn can correct the error. I think packages with a versioned depends on a provided package will be uninstallable with the current dpkg, right? If so that would only mean packages in etch+1 will be uninstallable without a prior update to a dpkg that handles versioned provides. Another example would be build-essential: Depends: libc6-dev | libc-dev, gcc (= 3:3.3), g++ (= 3:3.3), make, dpkg-dev (= 1.4.1.19) becomes Depends: libc6-dev:arch | libc-dev:arch, gcc (= 3:3.3), g++ (= 3:3.3), make, dpkg-dev (= 1.4.1.19), dpkg:arch Again a provides could be used to achieve the same effect. Actualy strike that. libc6-dev would not be Multi-Arch: no because the libc.so linker script is arch dependent. Dpkg then resolves the depends correctly already so that libc6-dev and build-essential always have the same architecture. Same for gcc and g++. Only the dpkg:arch is required and that can be done with Provides: dpkg-arch again. I believe this removes the need for a backwards-incompatible syntax change to the Depends: field, which is an objection I had to the posted dpkg v2 multiarch proposal as well. (Note that without this change to Depends: syntax, any of these multiarch packages can be installed fine on the native architecture with the existing dpkg, but that with this syntax change users must first upgrade to a new set of packaging tools before these package relationships are parseable.) I now agree with that with one reservation. For multiarch dpkg in the current WIP implementation to work correctly no future multiarch package may be installed with the existing dpkg. But if we get the other preparations into etch dpkg this can be caught in preinst of dpkg and the user can be instructed to first install etch dpkg, then reinstall affected packages. I think that is an acceptable limitation. So we don't have to change the syntax but we do have to change dpkg to smooth the way ahead for etch+1. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Multiarch preparations needed for etch dpkg
On Sat, May 20, 2006 at 10:27:35PM +0200, Goswin von Brederlow wrote: Matt Taggart and others [EMAIL PROTECTED] writes: Several people have been working on a project we've been calling multiarch, to seamlessly support running applications for multiple different binary targets on the same system. The main example being running i386-linux-gnu applications on amd64-linux-gnu systems, but many other working combinations exist. More info on Debian's multiarch efforts at http://wiki.debian.org/multiarch Part of implementing multiarch requires changes to dpkg. I've added another section to the wiki above listing the changes I would like to see implemented in etch dpkg in preparation for a future multiarch dpkg. I still think multiarch can be done in the current dpkg, esspecialy since I have an implementation that is 90% there. The listed changes are linked on the main page or directly under http://wiki.debian.org/dpkg-multiarch This comes down to 3 small changes with little to no impact on the current system but enabling features for the future: - Introduce the Multi-Arch field so sources can already set it - Store meta data with an arch tag when Multi-Arch: yes is set (Note that no package yet sets this. This is so packages can start using Multi-Arch: yes without confusing future dpkg about file locations.) I propose to use /var/lib/dpkg/info/pkg.arch.install as syntax. - Allow arch specific depends I propose to use Depends: pkg:arch (= 1.2-3) as syntax for thses. While for etch no package should use them dpkg should accept them so installing etch+1 debs can go without hitch. (Note that this also impacts on apt and aptitude) Please provide a counter-example to the following assertion: A multiarch package's dependency on another package must be satisfied by a package of a particular (i.e., of the same) architecture IFF the depended-on package is also a multi-arch package. If you don't have any counter-examples to this claim, then it's my belief that the last of these changes is not required, because versioned dependencies are enough to ensure the dependency is not incorrectly satisfied by a non-multiarch version of the package, and Multi-Arch: yes flags on the new versions of the package give dpkg front-ends enough information to correctly determine whether the dependency is properly satisfied and to resolve the dependency if not. I believe this removes the need for a backwards-incompatible syntax change to the Depends: field, which is an objection I had to the posted dpkg v2 multiarch proposal as well. (Note that without this change to Depends: syntax, any of these multiarch packages can be installed fine on the native architecture with the existing dpkg, but that with this syntax change users must first upgrade to a new set of packaging tools before these package relationships are parseable.) Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Multiarch preparations needed for etch dpkg
Steve Langasek [EMAIL PROTECTED] writes: On Sat, May 20, 2006 at 10:27:35PM +0200, Goswin von Brederlow wrote: - Allow arch specific depends I propose to use Depends: pkg:arch (= 1.2-3) as syntax for thses. While for etch no package should use them dpkg should accept them so installing etch+1 debs can go without hitch. (Note that this also impacts on apt and aptitude) Please provide a counter-example to the following assertion: A multiarch package's dependency on another package must be satisfied by a package of a particular (i.e., of the same) architecture IFF the depended-on package is also a multi-arch package. If you don't have any counter-examples to this claim, then it's my belief that the last of these changes is not required, because versioned dependencies are enough to ensure the dependency is not incorrectly satisfied by a non-multiarch version of the package, and Multi-Arch: yes flags on the new versions of the package give dpkg front-ends enough information to correctly determine whether the dependency is properly satisfied and to resolve the dependency if not. Say you have a binary package (Multi-Arch: no) firfox and a library/plugin package firefox-mplayer-plugin. This could be handled by firefox having a Provides: firefox-abiXX-arch-os-libc. Apt and perl for example already provide an abi pseudopackage. Another example would be build-essential: Depends: libc6-dev | libc-dev, gcc (= 3:3.3), g++ (= 3:3.3), make, dpkg-dev (= 1.4.1.19) becomes Depends: libc6-dev:arch | libc-dev:arch, gcc (= 3:3.3), g++ (= 3:3.3), make, dpkg-dev (= 1.4.1.19), dpkg:arch Again a provides could be used to achieve the same effect. I believe this removes the need for a backwards-incompatible syntax change to the Depends: field, which is an objection I had to the posted dpkg v2 multiarch proposal as well. (Note that without this change to Depends: syntax, any of these multiarch packages can be installed fine on the native architecture with the existing dpkg, but that with this syntax change users must first upgrade to a new set of packaging tools before these package relationships are parseable.) Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ The changes (to dpkg) required for the new depends syntax are rather simple. The only non trivial change is in lib/fields.c in the actual parser. * Add arch specific dependencies + lib/fields.c: Allow ':arch' in f_dependency() + lib/dpkg-db.h: struct deppossi: add const char *edname + lib/fields.c: f_dependency(): preserve deppossi-edname + src/processarc.c: process_archive(): copy deppossi-edname accross + Use edname instead of ed-name in: - lib/dump.c: w_dependency() - dselect/pkgsublist.cc - dselect/pkgdepcon.cc - src/archives.c - src/remove.c - src/depcon.c - src/processarc.c - src/packages.c I think we should add the new syntax for future use instead of requiring provides for this since provides can't be versioned and therefore have to have the versioning inside the name. Actual use of this feature could be delayed till etch+1 or etch+2 depending on how much time we allow for updaters. But isn't the rule that you have to update one release at a time and can't savely omit one? Users of etch+1 would be expected to have an etch dpkg then. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
