Re: 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 '[<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
Reply to: