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 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 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
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
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: : (>= 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
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: : (>= 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]
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/..install as syntax. > - Allow arch specific depends > I propose to use "Depends: : (>= 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
Multiarch preparations needed for etch dpkg
Matt Taggart and others <[EMAIL PROTECTED]> writes: > Hi debian-dpkg, > > 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/..install as syntax. - Allow arch specific depends I propose to use "Depends: : (>= 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) The wiki has more details on each of the 3 steps. I'm preparing patches for this but I would like to hear any comments, specificaly on the syntax to be used, before I submit any. No point in submitting a patch if the syntax then has to be changed. If those 3 changes are accepted into dpkg for etch then there should be no special steps needed in etch+1 to convert a system from uni-arch to multi-arch. A simple dpkg upgrade should do the trick. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
