Bug#585767: Dependencies on linux-gnu or not+linux-gnu do not match armel or powerpcspe correctly
* Guillem Jover | 2010-06-23 02:40:32 [+0200]: Hi! Hi, Nope, arch wildcards are just superior. Good. Debian Policy 3.9.0.0 just hit unstable and apt's apt-get build-dep seems to be fixed. Time to fill bugs and ask maintainers to remove not+linux-gnu and friends, isn't it? If so I think I go with the following mail: |Package Version Tag |Severity: Serious because it breaks armel or just important because we | want to get rid of linux-gnu types? | |Dear package maintainer, this is mass bug. |This package uses the keywords linux-gnu, not+linux-gnu or the kfreebsd- |variant of the former in its depends or architectur field in the |control file. Please be aware that linux-gnu excludes armel which |might not be what you want. |Since Debian Policy 3.9.0.0 architectur wildcards are defined for |Depends: [0] and Architecture: [1] are defined. You are encouraged to |start using them. |A quick cheat-list for the dependebcy would be: |$DEPENDENCY | not+linux-gnu = $DEPENDENCY [linux-any] |$DEPENDENCY | not+linux = $DEPENDENCY [linux-any] |$DEPENDENCY | linux-gnu = $DEPENDENCY [!linux-any] |$DEPENDENCY | linux = $DEPENDENCY [!linux-any] |$DEPENDENCY | not+hurd= $DEPENDENCY [hurd-any] |$DEPENDENCY | hurd= $DEPENDENCY [!hurd-any] | |Once no package is using this kind of dependency the relvant keywords |will be removed from the type-handling package which provides them. | |[0] http://www.debian.org/doc/debian-policy/ch-relationships.html#s-depsyntax |[1] http://www.debian.org/doc/debian-policy/ch-customized-programs.html#s-arch-spec | Any comments? Does the new policy make type-handling obselete since dpkg provides it? Mostly, type-handling should eventually disappear, as Aurelien has said it's just a hack. But, there's one case where it might unfortunately still be needed, which is an arch:all package conditionally depending on arch:foo packages only on the foo architecture. Do you have an example package handy? I'm happy once the linux-any friends keywords are gone :) regards, guillem Sebastian -- 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/20100628211125.gb10...@chamillionaire.breakpoint.cc
Bug#585767: Dependencies on linux-gnu or not+linux-gnu do not match armel or powerpcspe correctly
On Mo, 2010-06-21 at 23:09 +0200, Julian Andres Klode wrote: On Mo, 2010-06-21 at 21:56 +0200, Aurelien Jarno wrote: On Mon, Jun 21, 2010 at 08:35:14PM +0200, Sebastian Andrzej Siewior wrote: * Aurelien Jarno | 2010-06-14 12:00:14 [+0200]: libudev-dev (= 0.139) | not+linux-gnu, libhal-dev (= 0.5.10) | linux-gnu, I don't think it's a bug. The system type on those architectures is linux-gnuspe or linux-gnueabi, not linux-gnu. If you only want to match on the OS, you should use the linux and not+linux instead. This make sense. So I'm going to mass open bugs against every package which uses linux-gnu and tell them to use linux-any which becomes policy once #530687. Is this intended? There is actually no reason to use linux-gnu instead of linux-any, is there[0]? Does the new policy make type-handling obselete since dpkg provides it? type-handling has always been a bit hack, with the (long term) goal to remove it. It had no replacement until not so long ago, as the build daemons software was not able to handle it. Now that it has been fixed, we should certainly get rid of it. Architecture wildcards should not be used prior to Squeeze + 1. They are currently not implemented by APT and other programs using libapt-pkg to parse build-dependencies, and I do not know whether software such as sbuild supports it. I do not know whether we already have a bug report about it in APT; and I do not know whether the other packages have bug reports; it would be great if someone could take a look at this, so the toolchain can be fixed to support wildcards before we start using them. I just pushed revision 1995 to the debian-experimental-ma repository which adds support for architecture wild cards by replacing any with '*' and calling fnmatch() to check whether the wildcard matches either * the current architecture * the current architecture prefixed with 'linux-' Further information can be found in Bug#547724. Regards, Julian -- Julian Andres Klode - Debian Developer, Ubuntu Member See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/. -- 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/1277579742.2388.17.ca...@hp
Bug#585767: Dependencies on linux-gnu or not+linux-gnu do not match armel or powerpcspe correctly
* Aurelien Jarno | 2010-06-14 12:00:14 [+0200]: libudev-dev (= 0.139) | not+linux-gnu, libhal-dev (= 0.5.10) | linux-gnu, I don't think it's a bug. The system type on those architectures is linux-gnuspe or linux-gnueabi, not linux-gnu. If you only want to match on the OS, you should use the linux and not+linux instead. This make sense. So I'm going to mass open bugs against every package which uses linux-gnu and tell them to use linux-any which becomes policy once #530687. Is this intended? There is actually no reason to use linux-gnu instead of linux-any, is there[0]? Does the new policy make type-handling obselete since dpkg provides it? [0] Assuming that linux-any is not allowed by policy is not a reason. Sebastian -- 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/20100621183514.ga7...@chamillionaire.breakpoint.cc
Bug#585767: Dependencies on linux-gnu or not+linux-gnu do not match armel or powerpcspe correctly
On Mon, Jun 21, 2010 at 08:35:14PM +0200, Sebastian Andrzej Siewior wrote: * Aurelien Jarno | 2010-06-14 12:00:14 [+0200]: libudev-dev (= 0.139) | not+linux-gnu, libhal-dev (= 0.5.10) | linux-gnu, I don't think it's a bug. The system type on those architectures is linux-gnuspe or linux-gnueabi, not linux-gnu. If you only want to match on the OS, you should use the linux and not+linux instead. This make sense. So I'm going to mass open bugs against every package which uses linux-gnu and tell them to use linux-any which becomes policy once #530687. Is this intended? There is actually no reason to use linux-gnu instead of linux-any, is there[0]? Does the new policy make type-handling obselete since dpkg provides it? type-handling has always been a bit hack, with the (long term) goal to remove it. It had no replacement until not so long ago, as the build daemons software was not able to handle it. Now that it has been fixed, we should certainly get rid of it. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- 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/20100621195615.gb16...@hall.aurel32.net
Bug#585767: Dependencies on linux-gnu or not+linux-gnu do not match armel or powerpcspe correctly
On Mo, 2010-06-21 at 21:56 +0200, Aurelien Jarno wrote: On Mon, Jun 21, 2010 at 08:35:14PM +0200, Sebastian Andrzej Siewior wrote: * Aurelien Jarno | 2010-06-14 12:00:14 [+0200]: libudev-dev (= 0.139) | not+linux-gnu, libhal-dev (= 0.5.10) | linux-gnu, I don't think it's a bug. The system type on those architectures is linux-gnuspe or linux-gnueabi, not linux-gnu. If you only want to match on the OS, you should use the linux and not+linux instead. This make sense. So I'm going to mass open bugs against every package which uses linux-gnu and tell them to use linux-any which becomes policy once #530687. Is this intended? There is actually no reason to use linux-gnu instead of linux-any, is there[0]? Does the new policy make type-handling obselete since dpkg provides it? type-handling has always been a bit hack, with the (long term) goal to remove it. It had no replacement until not so long ago, as the build daemons software was not able to handle it. Now that it has been fixed, we should certainly get rid of it. Architecture wildcards should not be used prior to Squeeze + 1. They are currently not implemented by APT and other programs using libapt-pkg to parse build-dependencies, and I do not know whether software such as sbuild supports it. I do not know whether we already have a bug report about it in APT; and I do not know whether the other packages have bug reports; it would be great if someone could take a look at this, so the toolchain can be fixed to support wildcards before we start using them. Regards, Julian -- Julian Andres Klode - Debian Developer, Ubuntu Member See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/. -- 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/1277154587.3890.17.ca...@hp
Bug#585767: Dependencies on linux-gnu or not+linux-gnu do not match armel or powerpcspe correctly
retitle 585767 Meta Bug: Convert all deps on type-handling to arch-wildcards and remove type-handling severity 585767 wishlist thanks On Jun 21, 2010, at 15:56, Aurelien Jarno wrote: On Mon, Jun 21, 2010 at 08:35:14PM +0200, Sebastian Andrzej Siewior wrote: * Aurelien Jarno | 2010-06-14 12:00:14 [+0200]: libudev-dev (= 0.139) | not+linux-gnu, libhal-dev (= 0.5.10) | linux-gnu, I don't think it's a bug. The system type on those architectures is linux-gnuspe or linux-gnueabi, not linux-gnu. If you only want to match on the OS, you should use the linux and not+linux instead. This make sense. So I'm going to mass open bugs against every package which uses linux-gnu and tell them to use linux-any which becomes policy once #530687. Is this intended? There is actually no reason to use linux-gnu instead of linux-any, is there[0]? Does the new policy make type-handling obselete since dpkg provides it? type-handling has always been a bit hack, with the (long term) goal to remove it. It had no replacement until not so long ago, as the build daemons software was not able to handle it. Now that it has been fixed, we should certainly get rid of it. Ok, just to confirm, dependencies should be rewritten along these lines: $DEPENDENCY | not+linux-gnu = $DEPENDENCY [linux-any] $DEPENDENCY | not+linux = $DEPENDENCY [linux-any] $DEPENDENCY | linux-gnu = $DEPENDENCY [!linux-any] $DEPENDENCY | linux = $DEPENDENCY [!linux-any] $DEPENDENCY | not+hurd= $DEPENDENCY [hurd-any] $DEPENDENCY | hurd= $DEPENDENCY [!hurd-any] Since there are already a number of packages with dependencies like these in squeeze, it should be possible for maintainers to apply these changes right now, correct? Thanks again! Cheers, Kyle Moffett -- 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/15b9b824-1f62-48ff-b749-b331982b1...@boeing.com
Bug#585767: Dependencies on linux-gnu or not+linux-gnu do not match armel or powerpcspe correctly
On Mon, Jun 21, 2010 at 11:09:47PM +0200, Julian Andres Klode wrote: On Mo, 2010-06-21 at 21:56 +0200, Aurelien Jarno wrote: On Mon, Jun 21, 2010 at 08:35:14PM +0200, Sebastian Andrzej Siewior wrote: * Aurelien Jarno | 2010-06-14 12:00:14 [+0200]: libudev-dev (= 0.139) | not+linux-gnu, libhal-dev (= 0.5.10) | linux-gnu, I don't think it's a bug. The system type on those architectures is linux-gnuspe or linux-gnueabi, not linux-gnu. If you only want to match on the OS, you should use the linux and not+linux instead. This make sense. So I'm going to mass open bugs against every package which uses linux-gnu and tell them to use linux-any which becomes policy once #530687. Is this intended? There is actually no reason to use linux-gnu instead of linux-any, is there[0]? Does the new policy make type-handling obselete since dpkg provides it? type-handling has always been a bit hack, with the (long term) goal to remove it. It had no replacement until not so long ago, as the build daemons software was not able to handle it. Now that it has been fixed, we should certainly get rid of it. Architecture wildcards should not be used prior to Squeeze + 1. They are currently not implemented by APT and other programs using libapt-pkg to parse build-dependencies, and I do not know whether software such as sbuild supports it. sbuild already supports that, and there are already a few packages in the archive using architecture wildcards. I do not know whether we already have a bug report about it in APT; and I do not know whether the other packages have bug reports; it would be great if someone could take a look at this, so the toolchain can be fixed to support wildcards before we start using them. I don't think of any other package than apt. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- 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/20100621212359.gc16...@hall.aurel32.net
Bug#585767: Dependencies on linux-gnu or not+linux-gnu do not match armel or powerpcspe correctly
On Mon, Jun 21, 2010 at 03:22:37PM -0500, Moffett, Kyle D wrote: retitle 585767 Meta Bug: Convert all deps on type-handling to arch-wildcards and remove type-handling severity 585767 wishlist thanks On Jun 21, 2010, at 15:56, Aurelien Jarno wrote: On Mon, Jun 21, 2010 at 08:35:14PM +0200, Sebastian Andrzej Siewior wrote: * Aurelien Jarno | 2010-06-14 12:00:14 [+0200]: libudev-dev (= 0.139) | not+linux-gnu, libhal-dev (= 0.5.10) | linux-gnu, I don't think it's a bug. The system type on those architectures is linux-gnuspe or linux-gnueabi, not linux-gnu. If you only want to match on the OS, you should use the linux and not+linux instead. This make sense. So I'm going to mass open bugs against every package which uses linux-gnu and tell them to use linux-any which becomes policy once #530687. Is this intended? There is actually no reason to use linux-gnu instead of linux-any, is there[0]? Does the new policy make type-handling obselete since dpkg provides it? type-handling has always been a bit hack, with the (long term) goal to remove it. It had no replacement until not so long ago, as the build daemons software was not able to handle it. Now that it has been fixed, we should certainly get rid of it. Ok, just to confirm, dependencies should be rewritten along these lines: $DEPENDENCY | not+linux-gnu = $DEPENDENCY [linux-any] $DEPENDENCY | not+linux = $DEPENDENCY [linux-any] $DEPENDENCY | linux-gnu = $DEPENDENCY [!linux-any] $DEPENDENCY | linux = $DEPENDENCY [!linux-any] It might be sometimes better to use [kfreebsd-any] or [hurd-any] or a combination of both. $DEPENDENCY | not+hurd= $DEPENDENCY [hurd-any] $DEPENDENCY | hurd= $DEPENDENCY [!hurd-any] Same here. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- 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/20100621212501.gd16...@hall.aurel32.net
Bug#585767: Dependencies on linux-gnu or not+linux-gnu do not match armel or powerpcspe correctly
On Sun, Jun 13, 2010 at 02:04:35PM -0400, Kyle Moffett wrote: Package: dpkg Version: 1.15.7.2 Severity: important User: debian-powerpc...@breakpoint.cc Usertags: powerpcspe I'm actually a little unsure if this is a dpkg bug or a package bug, but I have had build failures from several packages which have Build-Depends like the following: (trimmed example from the gvfs-1.6.2-1 source package) libudev-dev (= 0.139) | not+linux-gnu, libfuse-dev | hurd, libhal-dev (= 0.5.10) | linux-gnu, libgdu-dev (= 2.29.0) | not+linux-gnu, libgudev-1.0-dev (= 001) | not+linux-gnu, libbluetooth-dev (= 4.0) | not+linux-gnu, libimobiledevice-dev (= 0.9.7) | hurd Unfortunately it seems like the powerpcspe and armel architectures do not provide the virtual packages linux-gnu and they do provide the virtual package not+linux-gnu, although if I change those deps to linux and not+linux then they behave as expected. I don't think it's a bug. The system type on those architectures is linux-gnuspe or linux-gnueabi, not linux-gnu. If you only want to match on the OS, you should use the linux and not+linux instead. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- 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/20100614100014.ga20...@volta.aurel32.net
Processed: Re: Bug#585767: Dependencies on linux-gnu or not+linux-gnu do not match armel or powerpcspe correctly
Processing commands for cont...@bugs.debian.org: reassign 585767 type-handling 0.2.23 Bug #585767 [dpkg] Dependencies on linux-gnu or not+linux-gnu do not match armel or powerpcspe correctly Bug reassigned from package 'dpkg' to 'type-handling'. Bug No longer marked as found in versions dpkg/1.15.7.2. Bug #585767 [type-handling] Dependencies on linux-gnu or not+linux-gnu do not match armel or powerpcspe correctly Bug Marked as found in versions type-handling/0.2.23. 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.12764563862526.transcr...@bugs.debian.org
Re: Bug#585767: Dependencies on linux-gnu or not+linux-gnu do not match armel or powerpcspe correctly
reassign 585767 type-handling 0.2.23 thanks Hi Kyle, On Sun, 13 Jun 2010, Kyle Moffett wrote: Package: dpkg Version: 1.15.7.2 Severity: important User: debian-powerpc...@breakpoint.cc Usertags: powerpcspe I'm actually a little unsure if this is a dpkg bug or a package bug, but I have had build failures from several packages which have Build-Depends like the following: (trimmed example from the gvfs-1.6.2-1 source package) libudev-dev (= 0.139) | not+linux-gnu, libfuse-dev | hurd, libhal-dev (= 0.5.10) | linux-gnu, libgdu-dev (= 2.29.0) | not+linux-gnu, libgudev-1.0-dev (= 001) | not+linux-gnu, libbluetooth-dev (= 4.0) | not+linux-gnu, libimobiledevice-dev (= 0.9.7) | hurd Unfortunately it seems like the powerpcspe and armel architectures do not provide the virtual packages linux-gnu and they do provide the virtual package not+linux-gnu, although if I change those deps to linux and not+linux then they behave as expected. This seems to be related to the fact that the triplettable entries for those architectures map them as linux-gnuspe and linux-gnueabi respectively, instead of linux-gnu. Those virtual packages are provided by the type-handling packages so I reassign it there if the provides are incorrect. On the other hand, I'm not entirely certain those package dependencies are compliant with current Debian Policy. I believe those package dependencies should be written as follows: libudev-dev (= 0.139) [linux-any], libfuse-dev [!hurd-any], libhal-dev (= 0.5.10) [!linux-any], libgdu-dev (= 2.29.0) [linux-any], libgudev-1.0-dev (= 001) [linux-any], libbluetooth-dev (= 4.0) [linux-any], libimobiledevice-dev (= 0.97) [!hurd-any] So I guess the question is whether the linux-gnu vs. not+linux-gnu behavior is correct, or alternatively whether or not it violates policy. You're right that it's best to use the real architectutre wildcards nowadays (#530687 it will be in policy soon). If the latter, perhaps dpkg-buildpackage should be patched to issue very loud warnings when those dependencies are detected as they are known to have incorrect behaviour on some platforms. That's rather a task for lintian. Cheers, -- Raphaƫl Hertzog Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/ My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/ -- 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/20100613191231.gb17...@rivendell