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

2011-11-16 Thread Robert Millan
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

2011-11-16 Thread Debian FTP Masters
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

2011-11-16 Thread Jakub Wilk

* 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

2011-11-16 Thread Guillem Jover
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

2011-11-16 Thread Debian Bug Tracking System
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

2011-11-16 Thread Paul Wise
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