On Wed, 14 Jan 2009 10:41:11 +0100 Adeodato Simó <d...@net.com.org.es> wrote:
> > >> Russ Allbery wrote: > > >> > It would be nice if there were some way of telling the archive software > > >> > not to include this package in the archive index on the platforms it > > >> > doesn't support, though. If there is a way of implementing this in the archive without involving the Packages.gz file, I'd like a method that can be supported by archive tools other than dak - like reprepro. This problem is having an impact on Emdebian where an Arch:all package should only exist on i386 and amd64: http://packages.debian.org/sid/acpi-support-base This package depends on acpid which is i386|amd64 only. The problem comes when acpi-support-base is included into an archive with something like reprepro and then the repository is checked with edos-debcheck. The lack of acpid on other architectures then results in an error on those architectures. Whichever solution is devised, I think it should apply beyond the realm on dak and beyond just affecting testing. > > > >> My proposal was > > >> http://lists.debian.org/debian-devel/2008/02/msg00045.html > > > > And an improved version which doesn't add unnecessary content was > > > offered too: > > > > http://lists.debian.org/debian-devel/2008/02/msg00355.html > > > > How about using (for example) > > > > Architecture: all [i386 amd64 ppc] I should just note that this was a suggestion by Goswin von Brederlow. I'm wondering if the change should be made in the other direction: Package: acpi-support-base Architecture: any Depends: acpid [i386|amd64] ? That's simpler and easily supported by existing tools (AFAICT). > > > This has two advantages over a separate line: > > > 1. it doesn't bloat the Packages.gz file (which is v.important for > > > embedded) > > > 2. it follows existing conventions for such data, e.g. build-depends > > > and depends lines, which means that existing tools require fewer > > > changes to process the new information The disadvantages of this method are also clear - a solution that does not rely on waiting for Squeeze+1 would be preferable. > > As this change is not backwards-compatible, the first time we could > > introduce > > such packages would be squeeze+1. > > Hm. I don't think that's the best approach, and while your willingness > to provide patches is commendable, I don't think starting right away > without consensus on how to go forward is the most reasonable thing to > do. :-) But, in any case, thanks for fostering the discussion. > > Here is my contribution to this matter: > > (1) The most straightforward way of getting this to work is *not* to > write to the Packages.gz file for a certain architecture arch:all > stanzas that are not installable in said architecture. How? Override file? > This is completely backwards compatible (¹), and doesn't require half of > our toolchain to grok anything. Which is certainly appealing. > (2) Doing the above just requires a patch to the software responsible > for generating Packages.gz files, which for unstable is dak. The main > *problem* is (always has been AIUI), what arch:all stanzas not to write? The problem also needs to be fixed in tools other than dak. > You may agree with Neil, that this should be specified in debian/control. > But this (a) puts the onus on the maintainer of a package to find out > whether a package is installable on every architecture or not, (b) find > out whether the situation is transient or permanent, and (c) make an > upload just to adjust the Architecture field whenever the situation > changes. I only commented on the suggestion - I'd much prefer a method that can be implemented before Squeeze+1. > Another option is taking the approach of P-a-s, and centralizing this > information somewhere, and have dak read that, and write Packages files > accordingly. The existing P-a-s infrastructure may, or may not be, > appropriate for this. And this approach itself may, or may not be, > appropriate itself. We'd have to discuss its merits and demerits. P-A-S ? > Yet another option is not doing anything for unstable, and fixing the > problem only in testing (and hence stable): britney already provides > information as to what arch:all packages are uninstallable, and where > (see [1]). Next britney version could as well not write these entries in > Packages.gz files for those arches. (If you check the size of [1], you > may see why using a central place à-la-P-a-s by hand, may not be such a > great idea after all.) I'm also not sure if this would be effort or not, > but it's an option nonetheless. > > Thoughts? I'd rather that this is fixed generically for all archive software and all suites. -- Neil Williams ============= http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/
pgprbOIxq9zYG.pgp
Description: PGP signature
