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 '[<os>-any]' and '[any-<cpu>]', 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]