[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, Jan 14, 2009 at 07:32:18PM +0000, Neil Williams wrote:
> Package: acpi-support-base
> Architecture: any
> Depends: acpid [i386|amd64]
I do not understand what you are proposing. The package would not be binary-indep
in your proposal (and the current syntax for depends is "acpid [i386 amd64]").

> That's simpler and easily supported by existing tools (AFAICT).
No, it's not really. Depends are parsed during the build-time, and dependencies
for non-matching architectures are removed from the binary package. But we are
talking about binary-indep packages, so this won't work.

This would be my other proposal, also known as Bug#436733:
  Package: acpi-support-base
  Architecture: all
  Depends: acpid [i386 amd64]

But in order to be correct, currently apt and co. do not support this. Therefore,
this could only be used in Squeeze+1 as well.


1. Architecture: all [arch1 arch2]
 This proposal is not backward compatible, but it would be very easy to
 do for the maintainer.
2. The one we discussed above.
 This is not backward compatible, but provides the most functionality of all
 proposals. And it can also be used to have an architecture independent packages
 depend on different packages (in case there is a package a on the one arch, and
 a package b on the other arch, but the package supports both); without half-broken
 The disadvantage is that the packages still appear in the Packages files, without
 being of use on the architecture. They may even contain broken symlinks, etc.

3. Install-Architecture field
 Adding a new field is backwards-compatible. But it would introduce a new field,
 which some do not like that much. Only programs creating repositories would need
 to be adapted.
4. An external location
 This is backward compatible too. The problem with this proposal is that it puts
 to a small group of people (if it would be implemented like some stuff we have
 already). Programs creating repositories would need to be changed to accept
 such a file.
 It is also not really normal, as we have the architecture list for architecture-dependant
 packages also in the source package.

If we want to do it in a better way, we should choose option 1 or 2. Even if we want
something different, option 2 would still be good to implement, because it makes life
easier and gives architecture-independent packages the same flexibility like
architecture-dependent ones.

The best seems to be a combination of 1 and 2, giving a lot of flexibility. If we want
something which we could start using with Squeeze, we should choose option 3.

Option 4 is not really a good idea, as the data should be contained in the packages themselves,
so people do not install a package not meant for their architecture.

Julian Andres Klode  - Free Software Developer
   Debian Developer  - Contributing Member of SPI
   Ubuntu Member     - Fellow of FSFE

Website: http://jak-linux.org/   XMPP: juliank@jabber.org
Debian:  http://www.debian.org/  SPI:  http://www.spi-inc.org/
Ubuntu:  http://www.ubuntu.com/  FSFE: http://www.fsfe.org/

Attachment: signature.asc
Description: Digital signature

Reply to: