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
freebsd-utils_8.2+ds2-11_kfreebsd-amd64.changes is NEW
devd_8.2+ds2-11_kfreebsd-amd64.deb to main/f/freebsd-utils/devd_8.2+ds2-11_kfreebsd-amd64.deb freebsd-geom_8.2+ds2-11_kfreebsd-amd64.deb to main/f/freebsd-utils/freebsd-geom_8.2+ds2-11_kfreebsd-amd64.deb freebsd-net-tools-udeb_8.2+ds2-11_kfreebsd-amd64.udeb to main/f/freebsd-utils/freebsd-net-tools-udeb_8.2+ds2-11_kfreebsd-amd64.udeb freebsd-net-tools_8.2+ds2-11_kfreebsd-amd64.deb to main/f/freebsd-utils/freebsd-net-tools_8.2+ds2-11_kfreebsd-amd64.deb freebsd-nfs-common_8.2+ds2-11_kfreebsd-amd64.deb to main/f/freebsd-utils/freebsd-nfs-common_8.2+ds2-11_kfreebsd-amd64.deb freebsd-nfs-server_8.2+ds2-11_kfreebsd-amd64.deb to main/f/freebsd-utils/freebsd-nfs-server_8.2+ds2-11_kfreebsd-amd64.deb freebsd-ppp_8.2+ds2-11_kfreebsd-amd64.deb to main/f/freebsd-utils/freebsd-ppp_8.2+ds2-11_kfreebsd-amd64.deb freebsd-utils-udeb_8.2+ds2-11_kfreebsd-amd64.udeb to main/f/freebsd-utils/freebsd-utils-udeb_8.2+ds2-11_kfreebsd-amd64.udeb freebsd-utils_8.2+ds2-11.debian.tar.gz to main/f/freebsd-utils/freebsd-utils_8.2+ds2-11.debian.tar.gz freebsd-utils_8.2+ds2-11.dsc to main/f/freebsd-utils/freebsd-utils_8.2+ds2-11.dsc freebsd-utils_8.2+ds2-11_kfreebsd-amd64.deb to main/f/freebsd-utils/freebsd-utils_8.2+ds2-11_kfreebsd-amd64.deb kbdcontrol-udeb_8.2+ds2-11_kfreebsd-amd64.udeb to main/f/freebsd-utils/kbdcontrol-udeb_8.2+ds2-11_kfreebsd-amd64.udeb kbdcontrol_8.2+ds2-11_kfreebsd-amd64.deb to main/f/freebsd-utils/kbdcontrol_8.2+ds2-11_kfreebsd-amd64.deb kldutils-udeb_8.2+ds2-11_kfreebsd-amd64.udeb to main/f/freebsd-utils/kldutils-udeb_8.2+ds2-11_kfreebsd-amd64.udeb kldutils_8.2+ds2-11_kfreebsd-amd64.deb to main/f/freebsd-utils/kldutils_8.2+ds2-11_kfreebsd-amd64.deb ktrace_8.2+ds2-11_kfreebsd-amd64.deb to main/f/freebsd-utils/ktrace_8.2+ds2-11_kfreebsd-amd64.deb (new) pf_8.2+ds2-11_kfreebsd-amd64.deb important net The OpenBSD Packet Filter Packet Filter (from here on referred to as PF) is OpenBSD's system for filtering TCP/IP traffic and doing Network Address Translation. PF is also capable of normalizing and conditioning TCP/IP traffic and providing bandwidth control and packet prioritization. . This version of PF has been ported to FreeBSD by the FreeBSD project, and subsequently to GNU/kFreeBSD by the Debian project. vidcontrol_8.2+ds2-11_kfreebsd-amd64.deb to main/f/freebsd-utils/vidcontrol_8.2+ds2-11_kfreebsd-amd64.deb Changes: freebsd-utils (8.2+ds2-11) unstable; urgency=low . * Unify all __unused fixes into a single patch. * Split PF into its own package. * Restore 040_kdump_multiarch.diff to fix FTBFS on kfreebsd-i386. Conflict with libc0.1-dev-i386 instead to fix kfreebsd-amd64. Override entries for your package: devd_8.2+ds2-11_kfreebsd-amd64.deb - important admin freebsd-geom_8.2+ds2-11_kfreebsd-amd64.deb - standard admin freebsd-net-tools-udeb_8.2+ds2-11_kfreebsd-amd64.udeb - important debian-installer freebsd-net-tools_8.2+ds2-11_kfreebsd-amd64.deb - important net freebsd-nfs-common_8.2+ds2-11_kfreebsd-amd64.deb - standard net freebsd-nfs-server_8.2+ds2-11_kfreebsd-amd64.deb - optional net freebsd-ppp_8.2+ds2-11_kfreebsd-amd64.deb - optional net freebsd-utils-udeb_8.2+ds2-11_kfreebsd-amd64.udeb - optional debian-installer freebsd-utils_8.2+ds2-11.dsc - source utils freebsd-utils_8.2+ds2-11_kfreebsd-amd64.deb - required utils kbdcontrol-udeb_8.2+ds2-11_kfreebsd-amd64.udeb - important debian-installer kbdcontrol_8.2+ds2-11_kfreebsd-amd64.deb - important utils kldutils-udeb_8.2+ds2-11_kfreebsd-amd64.udeb - optional debian-installer kldutils_8.2+ds2-11_kfreebsd-amd64.deb - important utils ktrace_8.2+ds2-11_kfreebsd-amd64.deb - optional utils vidcontrol_8.2+ds2-11_kfreebsd-amd64.deb - important utils Announcing to debian-devel-chan...@lists.debian.org Your package contains new components which requires manual editing of the override file. It is ok otherwise, so please be patient. New packages are usually added to the override file about once a week. You may have gotten the distribution wrong. You'll get warnings above if files already exist in other distributions. -- 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/e1rqlel-0007qy...@franck.debian.org
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
Processed: tagging 585767
Processing commands for cont...@bugs.debian.org: tags 585767 + wontfix Bug #585767 [type-handling] Dependencies on linux-gnu or not+linux-gnu do not match armel or powerpcspe correctly Added tag(s) wontfix. thanks Stopping processing here. Please contact me if you need assistance. -- 585767: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=585767 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.132149608017101.transcr...@bugs.debian.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