[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Arch:all package depending on package that isn't Arch:any



On Wed, 14 Jan 2009 10:41:11 +0100
Adeodato Simó <dato@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/

Attachment: pgp4OYOVDpkFx.pgp
Description: PGP signature


Reply to: