Bug#274747: dependency on dpkg-dev is not required for provides
On Mon, Oct 12, 2009 at 01:05:18PM +0200, Guillem Jover wrote:
> Hi!
>
> On Mon, 2009-10-12 at 10:54:07 +0200, Aurelien Jarno wrote:
> > On Sat, Oct 10, 2009 at 08:43:16PM -0700, Josh Triplett wrote:
> > > Package: type-handling
> > > Version: 0.2.23
> > > Severity: normal
> > >
> > > This issue has just become somewhat more commonplace:
> > > gnome-desktop-environment now uses type-handling, depending on
> > > "gnome-mount | linux-gnu", and on "policykit-1-gnome | not+linux-gnu".
> > > Note that gnome-desktop-environment, as a metapackage, uses
> > > "Architecture: all". This seems like a very useful application of
> > > type-handling.
> > >
> > > Please, consider splitting the provides into a separate package which
> > > does not depend on dpkg-dev.
> >
> > type-handling has always been a hack to workaround missing features of
> > dpkg-dev, and it should disappear asap.
> >
> > dpkg has already support for architecture aliases for a few years, as
> > far as I remember it can't be used due to missing support on the
> > build daemons.
> >
> > Could the dpkg team (Cc:ed) can give us a more detailed status of this
> > feature, so that we can push it for Squeeze?
>
> That only works for arch:any packages, here the problem is related to
> an arch:all package. The wildcards on arch:any packages should be
> mostly usable, last time I checked it was pending for all buildd to
> be switched to the new sbuild (which has such support).
>
> Adding wildcard support to arch:all packages would imply a wait time
> of one release before being usable, as the syntax of the dependncy
> fields would change.
>
> Another possibility is to switch the package to an arch:any one. It's
> a metapackages anyway so it does not take much space on the servers. And
> actually an argument could be made that an arch:all package which
> requires different dependencies on different architectures is not a
> trully arch:all package.
>
Another option is that all the Provides: part of type-handling is done
on dpkg. The current problem with the implementation:
- A rebuild of type-handling is needed each time a new architecture is
added to dpkg.
- Provides do not always work as an alternative. This require for
example type-handling to be installed on the build daemons
(technically it should be an Essential package for this to work).
That's why I am not really for more usage of type-handling, which IMHO
should simply disappear.
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurelien@aurel32.net http://www.aurel32.net
Reply to: