Re: Arch:all package depending on package that isn't Arch:any
(Dropping -mentors and rra@. Bcc ftpmaster@.)
* Julian Andres Klode [Wed, 14 Jan 2009 08:06:43 +0100]:
> 2009/1/13 Neil Williams <codehelp@debian.org>:
> > On Tue, 13 Jan 2009 08:30:08 +0100
> > "Julian Andres Klode" <jak@debian.org> 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.
> >> 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]
> > 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
> > We don't have Build-Depends-Architecture or Depends-Architecture, so
> > why consider Install-Architecture? Fundamentally, these are the same
> > problem so the same solution would be useful.
> > What is needed now is for someone to pursue the idea with bug reports
> > and patches to get it implemented. Ideas are fine but someone needs to
> > do the work of identifying what needs to change and how to get it
> > working.
> If we copy this field 1:1 into the package and the Packages files, many
> packages will require patches, and the policy as well. I will try to provide
> patches for dpkg, dak, apt and python-apt, as well as the policy.
> 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.
This is completely backwards compatible (¹), and doesn't require half of
our toolchain to grok anything.
Changing the expectation that "Architecture" is a single word in
Packages files sounds like a bad idea. Whoever is parsing
binary-i386/Packages.gz, what do they care if a stanza there is present,
or not, in binary-amd64?
(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?
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.
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.
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?
[1]: http://release.debian.org/britney/testing_uninst_full.txt
Footnotes:
(¹) Well, backwards compatible with out *tools*. You break the
expectation that grepping against any Packages.gz file will give you
all arch:all packages by default, eg.
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
Truth is the most valuable thing we have, so let's economize it.
-- Mark Twain
Reply to: