Bug#274747: type-handling: 274747: dpkg-dev dependency removal

[Guillem Jover <guillem@debian.org>]

Hi!

On Thu, 2011-11-17 at 00:58:30 +0100, Jakub Wilk wrote:
> * Robert Millan <rmh@debian.org>, 2011-11-16, 18:18:
> >>I just added Depends: linux to iotop (arch all, written in
> >>python and depends on a Linux kernel) before I realised that
> >>type-handling pulls in dpkg-dev. I would really appreciate it if
> >>the type-handling Provides were split off into a second package,
> >>or maybe dpkg is the right place for the Provides?

dpkg is not the right place for the Provides, those are a hack, are
overstepping on the package name space, and they should really go.

The only reason this has not happened yet is because there's still
packages depending on it on the archive.

There's also the other questionable reasons related to arch:all
packages. Used up to now to either be able to conditionalize arch
specific dependencies or as in your case to make it uninstallable
on specific arches.

But I'd argue that both those usages are bogus:

 * For the first one, if the script is portable and can work w/o the
   specific dependency on other systems, then that implies it should
   not be a Depends but a Recommends, so no need for the Provides.

 * The second case comes from conflating the two roles of arch:all
   packages, saving archive space by avoiding duplication sharing
   the same files across arches and shipping truly arch independent
   files/scripts. In the iotop case the scripts are not arch independent
   even if they are shareable. Restricting it by uninstallability is
   just another hack, the users on a package manager frontend will
   wonder why they are shown a packages they cannot possibly install,
   the Packages files get unneedingly bloated, etc. A possible clean
   solution to this could be something like: linux-all, all-i386, etc,
   for example which was discussed already during the design of the
   arch wildcards.

> >Given that there are only two packages that still use
> >type-handling in their Build-Depends (e2tools and gdb),
> 
> (There's also control-center, which is fixed only in experimental.)
> 
> >and that both have bugs tagged pending that fix that, I think the
> >dpkg-dev dependency can just be removed.
> 
> dpkg-dev is build-essential, so it shouldn't make a difference for
> packages build-depending on it.
> 
> buildcross (in experimental) depends on type-handling, though I
> don't know why.

> There are also some users of virtual packages provided by type-handling:

> Source: coreutils
> Build-Depends: ..., libattr1-dev | not+linux-gnu, libacl1-dev | not+linux-gnu, libselinux1-dev (>= 1.32) | not+linux-gnu, ...
> 
> Source: mc
> Build-Depends: ..., libgpm-dev | not+linux-gnu, ...
> 
> Source: ntp
> Build-Depends: ..., libcap2-dev | not+linux-gnu, ...
> 
> Package: usb-modeswitch-data
> Depends: udev (>= 0.140) | not+linux-gnu
> 
> Package: iotop
> Depends: ..., linux

Ah, thanks for the list Jakub! Is that exhaustive, against all
possible Provides generated by type-handling or only a selected few?

> Given how little used type-handling is, maybe it's time to remove it?

Yes, see:

  <http://lists.debian.org/debian-bsd/2011/10/msg00199.html>

I'll be filing bug reports against those packages to switch to arch
wildcards if no one beats me to it eventually. In addition those have
the problem that they will not match on things like linux-gnueabi for
example.

thanks,
guillem