Bug#454057: please move dpkg-architecture
Hi, On Wed, 2007-12-05 at 20:02:34 +0100, Aurelien Jarno wrote: > Raphael Hertzog a écrit : > > On Wed, 05 Dec 2007, Julien Cristau wrote: > > > > Maybe type-handling could be split with an empty package whose sole > > > > purpose is to "Provides" some virtual packages while type-handling > > > > stays the program with its dpkg-dev dependency. > > > > > > > > I think this solution would be my first preference. I've been meaning to discuss this with the XSF but at some point forgot about it. I'd really like if you guys could switch that package to arch:any (reasons given below). > > > My preference would be for dpkg to allow 'Depends: foo [arch]' in > > > arch:all packages, but failing that, I agree. > > Right now the support for the "[arch]" syntax is only in the perl code > > and not at all in the C part that concerns dpkg. Adding it there is a > > non-trivial effort and would probably also require changes in apt-based > > software. The '[arch]' is supported in the perl code but the dependencies are reduced at package build time. The C code is not the problem with this solution (implementing this is not that difficult, although the arch wildcard support would have to be reimplemented in C), the main problem is breaking all programs around that might be parsing the dependency fields, like sbuild, pbuilder, apt-based, etc. > > Aurélien, what do you think of the idea of change concerning type-handling ? > From my point of view, we should get rid of type-handling as soon as > possible. This is actually a big and buggy hack to workaround dpkg/apt > lacks. Agreed, and that was our main goal when we (although it has been Aurélien who has done all the work) took over that package. Part of the failure is probably on me for not having pushed enough for the arch wildcards... > The first think I would like to see, is [os] or [cpu] support in > dpkg-dev *enabled* and *allowed* for arch-any packages. This would > replace type-handling in 90% of the cases. I suppose you mean the arch wildcards like '[-any]' and '[any-]', this has been supported since latest part of the etch release which is the most annoying part type-handling is working around and that's the reason it got added then, to be able to easily get rid of type-handling. The only reason we cannnot use it now is sbuild, I sent a mail to Ryan some time ago but he didn't reply. > For the [arch] support in binary-all packages, I guess the main use case > (if not all) is for metapackages depending on various packages. I don't > really see the problem (except the policy, but that can be changed) of > using binary-any packages for those metapackages, even if there is no > binary files insude them. They are by definition very small, so that > won't bloat the archive. I agree. There's probably really few cases where an arch:all needs to Depend on a package only present in a specific architecture. I'm not sure it's worth the effort, also ideally we should have less arch specific packages. > If there are still some cases not solved by this approach, I guess the > package that should provide the not+sparc package is dpkg. It is always > installed on systems, so strange behaviours of apt with virtual packages > is avoided. Right, but I'm a bit uneasy on this solution of abusing the dependencies for that purpose. I'll be closing this bug report and the one on type-handling about splitting the package in few days. regards, guillem
Bug#454057: please move dpkg-architecture
Raphael Hertzog a écrit : > On Wed, 05 Dec 2007, Julien Cristau wrote: >>> Or we can change type-handling too. Apparently xorg only uses the fact >>> that type-handling provides not+sparc but it doesn't use the type-handling >>> program which is the real user of dpkg-architecture. Is that right? >> Yes, that's correct. >> >>> Maybe type-handling could be split with an empty package whose sole >>> purpose is to "Provides" some virtual packages while type-handling >>> stays the program with its dpkg-dev dependency. >>> >>> I think this solution would be my first preference. >>> >> My preference would be for dpkg to allow 'Depends: foo [arch]' in arch:all >> packages, but failing that, I agree. > > Right now the support for the "[arch]" syntax is only in the perl code > and not at all in the C part that concerns dpkg. Adding it there is a > non-trivial effort and would probably also require changes in apt-based > software. > > Aurélien, what do you think of the idea of change concerning type-handling ? > >From my point of view, we should get rid of type-handling as soon as possible. This is actually a big and buggy hack to workaround dpkg/apt lacks. The first think I would like to see, is [os] or [cpu] support in dpkg-dev *enabled* and *allowed* for arch-any packages. This would replace type-handling in 90% of the cases. For the [arch] support in binary-all packages, I guess the main use case (if not all) is for metapackages depending on various packages. I don't really see the problem (except the policy, but that can be changed) of using binary-any packages for those metapackages, even if there is no binary files insude them. They are by definition very small, so that won't bloat the archive. If there are still some cases not solved by this approach, I guess the package that should provide the not+sparc package is dpkg. It is always installed on systems, so strange behaviours of apt with virtual packages is avoided. That's why we have type-handling installed on GNU/kFreeBSD build daemons by default (GNU/kFreeBSD uses type-handling more than other architectures). -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#454057: please move dpkg-architecture
On Wed, 05 Dec 2007, Julien Cristau wrote: > > Or we can change type-handling too. Apparently xorg only uses the fact > > that type-handling provides not+sparc but it doesn't use the type-handling > > program which is the real user of dpkg-architecture. Is that right? > > Yes, that's correct. > > > Maybe type-handling could be split with an empty package whose sole > > purpose is to "Provides" some virtual packages while type-handling > > stays the program with its dpkg-dev dependency. > > > > I think this solution would be my first preference. > > > My preference would be for dpkg to allow 'Depends: foo [arch]' in arch:all > packages, but failing that, I agree. Right now the support for the "[arch]" syntax is only in the perl code and not at all in the C part that concerns dpkg. Adding it there is a non-trivial effort and would probably also require changes in apt-based software. Aurélien, what do you think of the idea of change concerning type-handling ? Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
Bug#454057: please move dpkg-architecture
On Wed, Dec 5, 2007 at 00:14:53 +0100, Raphael Hertzog wrote: > Or we can change type-handling too. Apparently xorg only uses the fact > that type-handling provides not+sparc but it doesn't use the type-handling > program which is the real user of dpkg-architecture. Is that right? > Yes, that's correct. > Maybe type-handling could be split with an empty package whose sole > purpose is to "Provides" some virtual packages while type-handling > stays the program with its dpkg-dev dependency. > > I think this solution would be my first preference. > My preference would be for dpkg to allow 'Depends: foo [arch]' in arch:all packages, but failing that, I agree. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#454057: please move dpkg-architecture
On Mon, 03 Dec 2007, Robert Millan wrote: > On Sun, Dec 02, 2007 at 09:42:17PM +0100, Raphael Hertzog wrote: > > On Sun, 02 Dec 2007, Robert Millan wrote: > > > Please could you move dpkg-architecture from dpkg-dev to dpkg ? It seems > > > that > > > because of this, it turns out that having the xorg meta-package installed > > > requires dpkg-dev and hence binutils (because of type-handling). > > > > dpkg-architecture is perl and the goal is rather to get rid of perl in > > dpkg than the contrary. So my first vote is against this change. > > Note that it's trivial to re-write in bash, though. > > > Why does xorg need dpkg-architecture ? > > Because of type-handling. Maybe we should change that instead... > > X11 maintainers, how would you feel about making 'xorg' a binary-arch > package so that it can use [] arch specifiers? Or we can change type-handling too. Apparently xorg only uses the fact that type-handling provides not+sparc but it doesn't use the type-handling program which is the real user of dpkg-architecture. Is that right? Maybe type-handling could be split with an empty package whose sole purpose is to "Provides" some virtual packages while type-handling stays the program with its dpkg-dev dependency. I think this solution would be my first preference. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
Bug#454057: please move dpkg-architecture
On Sun, Dec 02, 2007 at 09:42:17PM +0100, Raphael Hertzog wrote: > On Sun, 02 Dec 2007, Robert Millan wrote: > > Please could you move dpkg-architecture from dpkg-dev to dpkg ? It seems > > that > > because of this, it turns out that having the xorg meta-package installed > > requires dpkg-dev and hence binutils (because of type-handling). > > dpkg-architecture is perl and the goal is rather to get rid of perl in > dpkg than the contrary. So my first vote is against this change. Note that it's trivial to re-write in bash, though. > Why does xorg need dpkg-architecture ? Because of type-handling. Maybe we should change that instead... X11 maintainers, how would you feel about making 'xorg' a binary-arch package so that it can use [] arch specifiers? -- Robert Millan I know my rights; I want my phone call! What use is a phone call, if you are unable to speak? (as seen on /.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#454057: please move dpkg-architecture
On Sun, 02 Dec 2007, Robert Millan wrote: > Please could you move dpkg-architecture from dpkg-dev to dpkg ? It seems that > because of this, it turns out that having the xorg meta-package installed > requires dpkg-dev and hence binutils (because of type-handling). dpkg-architecture is perl and the goal is rather to get rid of perl in dpkg than the contrary. So my first vote is against this change. Why does xorg need dpkg-architecture ? Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
Bug#454057: please move dpkg-architecture
Package: dpkg-dev Version: 1.13.25 Severity: normal Please could you move dpkg-architecture from dpkg-dev to dpkg ? It seems that because of this, it turns out that having the xorg meta-package installed requires dpkg-dev and hence binutils (because of type-handling). -- System Information: Debian Release: lenny/sid APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-5-amd64 Locale: LANG=ca_AD.UTF-8, LC_CTYPE=ca_AD.UTF-8 (charmap=UTF-8) Versions of packages dpkg-dev depends on: ii binutils2.17-3 The GNU assembler, linker and bina ii cpio2.6-17 GNU cpio -- a program to manage ar ii dpkg1.13.25 package maintenance system for Deb ii make3.81-3 The GNU version of the "make" util ii patch 2.5.9-4 Apply a diff file to an original ii perl [perl5]5.8.8-7etch1 Larry Wall's Practical Extraction ii perl-modules5.8.8-7etch1 Core Perl modules Versions of packages dpkg-dev recommends: ii bcc [c-compiler] 0.16.14-1.4 16-bit x86 C compiler ii bzip21.0.3-6 high-quality block-sorting file co ii gcc [c-compiler] 4:4.1.1-15 The GNU C compiler ii gcc-3.4 [c-compiler] 3.4.6-5 The GNU C compiler ii gcc-4.0 [c-compiler] 4.0.3-7 The GNU C compiler ii gcc-4.1 [c-compiler] 4.1.1-21The GNU C compiler -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
