Bug#274747: type-handling: 274747: dpkg-dev dependency removal
Hi! On Fri, 2011-11-18 at 02:47:33 +0100, Jakub Wilk wrote: * Jakub Wilk jw...@debian.org, 2011-11-17, 12:18: Ah, thanks for the list Jakub! Is that exhaustive, against all possible Provides generated by type-handling or only a selected few? I believe it's exhaustive, but I'll double-check later today. I set up pages to track reverse (build-) dependencies: http://people.debian.org/~jwilk/type-handling/reverse-depends http://people.debian.org/~jwilk/type-handling/reverse-build-depends The code used to generate them is available here: http://people.debian.org/~jwilk/type-handling/Makefile Wonderful, thanks! regards, guillem -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2018180804.ga26...@gaara.hadrons.org
Bug#274747: type-handling: 274747: dpkg-dev dependency removal
* Guillem Jover guil...@debian.org, 2011-11-17, 03:11: 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? I believe it's exhaustive, but I'll double-check later today. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2017111802.ga1...@jwilk.net
Bug#274747: type-handling: 274747: dpkg-dev dependency removal
* Jakub Wilk jw...@debian.org, 2011-11-17, 12:18: 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? I believe it's exhaustive, but I'll double-check later today. I set up pages to track reverse (build-) dependencies: http://people.debian.org/~jwilk/type-handling/reverse-depends http://people.debian.org/~jwilk/type-handling/reverse-build-depends The code used to generate them is available here: http://people.debian.org/~jwilk/type-handling/Makefile -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2018014733.ga8...@jwilk.net
Bug#274747: type-handling: 274747: dpkg-dev dependency removal
Hi Paul, 2011/11/16 Paul Wise p...@debian.org: 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? Given that there are only two packages that still use type-handling in their Build-Depends (e2tools and gdb), and that both have bugs tagged pending that fix that, I think the dpkg-dev dependency can just be removed. -- Robert Millan -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOfDtXP6udVJce7rV=n=qe6m+4ldzaqnnvu-hdmkvhe0lhl...@mail.gmail.com
Bug#274747: type-handling: 274747: dpkg-dev dependency removal
* Robert Millan r...@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? 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 Given how little used type-handling is, maybe it's time to remove it? -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2016235830.ga8...@jwilk.net
Bug#274747: type-handling: 274747: dpkg-dev dependency removal
Hi! On Thu, 2011-11-17 at 00:58:30 +0100, Jakub Wilk wrote: * Robert Millan r...@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 -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2017021127.ga15...@gaara.hadrons.org
Bug#274747: type-handling: 274747: dpkg-dev dependency removal
On Thu, 2011-11-17 at 03:11 +0100, Guillem Jover wrote: 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 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. I have now switched iotop to Architecture: linux-any and dropped the Depends: linux. Unfortunately linux-all is not available yet. -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
