Re: Excluding a single arch on an arch: any
Wesley J. Landaker [EMAIL PROTECTED] writes: Hey folks, Is is possible to make the equivalent of an Architecture: any package except that it excludes one or two specific architectures? Basically, I'd like to be able to write, for example: Architecture: any [!ia64] I know I could specifically list supported architectures, but I don't want to do that, because the package in question works on *every architecture*, including unofficial ones (like hurd, knetbsd, etc) except for it has all sorts of perpetual, unresolvable problems on one particular architecture. I just want to exclude that specific one. % type-handling -n ia64 i386 darwin-i386 freebsd-i386 kfreebsd-i386 knetbsd-i386 netbsd-i386 openbsd-i386 hurd-i386 ia64 darwin-ia64 freebsd-ia64 kfreebsd-ia64 knetbsd-ia64 netbsd-ia64 openbsd-ia64 hurd-ia64 alpha darwin-alpha freebsd-alpha kfreebsd-alpha knetbsd-alpha netbsd-alpha openbsd-alpha hurd-alpha amd64 darwin-amd64 freebsd-amd64 kfreebsd-amd64 knetbsd-amd64 netbsd-amd64 openbsd-amd64 hurd-amd64 armeb darwin-armeb freebsd-armeb kfreebsd-armeb knetbsd-armeb netbsd-armeb openbsd-armeb hurd-armeb arm darwin-arm freebsd-arm kfreebsd-arm knetbsd-arm netbsd-arm openbsd-arm hurd-arm hppa darwin-hppa freebsd-hppa kfreebsd-hppa knetbsd-hppa netbsd-hppa openbsd-hppa hurd-hppa m32r darwin-m32r freebsd-m32r kfreebsd-m32r knetbsd-m32r netbsd-m32r openbsd-m32r hurd-m32r m68k darwin-m68k freebsd-m68k kfreebsd-m68k knetbsd-m68k netbsd-m68k openbsd-m68k hurd-m68k mips darwin-mips freebsd-mips kfreebsd-mips knetbsd-mips netbsd-mips openbsd-mips hurd-mips mipsel darwin-mipsel freebsd-mipsel kfreebsd-mipsel knetbsd-mipsel netbsd-mipsel openbsd-mipsel hurd-mipsel powerpc darwin-powerpc freebsd-powerpc kfreebsd-powerpc knetbsd-powerpc netbsd-powerpc openbsd-powerpc hurd-powerpc ppc64 darwin-ppc64 freebsd-ppc64 kfreebsd-ppc64 knetbsd-ppc64 netbsd-ppc64 openbsd-ppc64 hurd-ppc64 s390 darwin-s390 freebsd-s390 kfreebsd-s390 knetbsd-s390 netbsd-s390 openbsd-s390 hurd-s390 s390x darwin-s390x freebsd-s390x kfreebsd-s390x knetbsd-s390x netbsd-s390x openbsd-s390x hurd-s390x sh3 darwin-sh3 freebsd-sh3 kfreebsd-sh3 knetbsd-sh3 netbsd-sh3 openbsd-sh3 hurd-sh3 sh3eb darwin-sh3eb freebsd-sh3eb kfreebsd-sh3eb knetbsd-sh3eb netbsd-sh3eb openbsd-sh3eb hurd-sh3eb sh4 darwin-sh4 freebsd-sh4 kfreebsd-sh4 knetbsd-sh4 netbsd-sh4 openbsd-sh4 hurd-sh4 sh4eb darwin-sh4eb freebsd-sh4eb kfreebsd-sh4eb knetbsd-sh4eb netbsd-sh4eb openbsd-sh4eb hurd-sh4eb sparc darwin-sparc freebsd-sparc kfreebsd-sparc knetbsd-sparc netbsd-sparc openbsd-sparc hurd-sparc But to use that you need a debian/control.in file. Maybe a better solution would be to get ia64 excluded in Packages-Arch-Specific, leave the Architecture at any and make debian/rules fail with an explanation if build on ia64. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Excluding a single arch on an arch: any
On 2007-08-13, Goswin von Brederlow [EMAIL PROTECTED] wrote: % type-handling -n ia64 i386 darwin-i386 freebsd-i386 kfreebsd-i386 knetbsd-i386 netbsd-i386 pts seems to have problems with this: http://packages.qa.debian.org/w/wine.html - it at least looks quite ugly. /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Excluding a single arch on an arch: any
Wesley J. Landaker [EMAIL PROTECTED] writes: Is is possible to make the equivalent of an Architecture: any package except that it excludes one or two specific architectures? I think the best you can do is to write a check for that specific architecture in the package's preinst script, and abort the installation if it is being installed on that 'blacklisted' architecture. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 pgp8YqYQLpjNp.pgp Description: PGP signature
Re: Excluding a single arch on an arch: any
* Reinhard Tartler [Sun, 12 Aug 2007 21:27:50 +0200]: Wesley J. Landaker [EMAIL PROTECTED] writes: Is is possible to make the equivalent of an Architecture: any package except that it excludes one or two specific architectures? I think the best you can do is to write a check for that specific architecture in the package's preinst script, and abort the installation if it is being installed on that 'blacklisted' architecture. Uuh, that doesn't sound right. The correct thing to do would be to ensure the package does not build on the broken architectures, and remove the binaries from unstable. To do the former, and since the point is not having to list all possible architectures in the Architecture field, one can do in debian/rules: DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH) configure: test $(DEB_HOST_ARCH) != ia64 Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org - Blue flower, red thorns. This would be so much easier|if I wasn't colour-blind! -- Donkey in “Shrek” -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Excluding a single arch on an arch: any
Wesley J. Landaker [EMAIL PROTECTED] writes: Is is possible to make the equivalent of an Architecture: any package except that it excludes one or two specific architectures? * Reinhard Tartler [Sun, 12 Aug 2007 21:27:50 +0200]: I think the best you can do is to write a check for that specific architecture in the package's preinst script, and abort the installation if it is being installed on that 'blacklisted' architecture. Adeodato Simó [EMAIL PROTECTED] writes: Uuh, that doesn't sound right. The correct thing to do would be to ensure the package does not build on the broken architectures, and remove the binaries from unstable. To do the former, and since the point is not having to list all possible architectures in the Architecture field, one can do in debian/rules: DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH) configure: test $(DEB_HOST_ARCH) != ia64 I'm sorry, you're of course right. I've misread arch: any by arch: all. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4
Re: Excluding a single arch on an arch: any
On Sunday 12 August 2007 13:35:02 Adeodato Simó wrote: * Reinhard Tartler [Sun, 12 Aug 2007 21:27:50 +0200]: Wesley J. Landaker [EMAIL PROTECTED] writes: Is is possible to make the equivalent of an Architecture: any package except that it excludes one or two specific architectures? I think the best you can do is to write a check for that specific architecture in the package's preinst script, and abort the installation if it is being installed on that 'blacklisted' architecture. Uuh, that doesn't sound right. The correct thing to do would be to ensure the package does not build on the broken architectures, and remove the binaries from unstable. Won't this then prevent the package from migrating to testing, because it's arch: any, but failing to build on a release arch? -- Wesley J. Landaker [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] OpenPGP FP: 4135 2A3B 4726 ACC5 9094 0097 F0A9 8A4C 4CD6 E3D2 signature.asc Description: This is a digitally signed message part.
Re: Excluding a single arch on an arch: any
On Sun, Aug 12, 2007 at 05:43:27PM -0600, Wesley J. Landaker wrote: On Sunday 12 August 2007 13:35:02 Adeodato Simó wrote: * Reinhard Tartler [Sun, 12 Aug 2007 21:27:50 +0200]: Wesley J. Landaker [EMAIL PROTECTED] writes: Is is possible to make the equivalent of an Architecture: any package except that it excludes one or two specific architectures? I think the best you can do is to write a check for that specific architecture in the package's preinst script, and abort the installation if it is being installed on that 'blacklisted' architecture. Uuh, that doesn't sound right. The correct thing to do would be to ensure the package does not build on the broken architectures, and remove the binaries from unstable. Won't this then prevent the package from migrating to testing, because it's arch: any, but failing to build on a release arch? and remove the binaries from unstable. The criterion for migration to testing is *not*, and never has been, that the package build on architectures; the criterion is that the package must not have any out-of-date binaries in unstable, which can be dealt with by 1) making sure the package builds on all architectures, 2) getting the ftp team to agree to remove the out-of-date binaries, or 3) ensuring in advance that the package never gets built on architectures where it doesn't belong. This is a proxy for the requirement that packages be supported on as many architectures as is reasonably possible. If the package is not supported on a given architecture, the binaries of that package for the architecture in question should not be in the archive (and particularly, not in testing), but it is *not* the role of the testing migration scripts to make decisions about whether a package is supported for an architecture, only to ensure consistency between architectures. The decision of whether a package is supported is one that has to be made by the package maintainer and the porters. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Excluding a single arch on an arch: any
On Sunday 12 August 2007 19:13:38 Steve Langasek wrote: On Sun, Aug 12, 2007 at 05:43:27PM -0600, Wesley J. Landaker wrote: Won't this then prevent the package from migrating to testing, because it's arch: any, but failing to build on a release arch? and remove the binaries from unstable. The criterion for migration to testing is *not*, and never has been, that the package build on architectures; the criterion is that the package must not have any out-of-date binaries in unstable, which can be dealt with by 1) making sure the package builds on all architectures, 2) getting the ftp team to agree to remove the out-of-date binaries, or 3) ensuring in advance that the package never gets built on architectures where it doesn't belong. Ah, okay. The package in question does have an out-of-date binary that previously built without problems (but AFAICT doesn't actually work). This is a proxy for the requirement that packages be supported on as many architectures as is reasonably possible. If the package is not supported on a given architecture, the binaries of that package for the architecture in question should not be in the archive (and particularly, not in testing), but it is *not* the role of the testing migration scripts to make decisions about whether a package is supported for an architecture, only to ensure consistency between architectures. The decision of whether a package is supported is one that has to be made by the package maintainer and the porters. Thanks all for the tips and clarification. I believe I know how to proceed sanely now. =) -- Wesley J. Landaker [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] OpenPGP FP: 4135 2A3B 4726 ACC5 9094 0097 F0A9 8A4C 4CD6 E3D2 signature.asc Description: This is a digitally signed message part.
