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. Summary -------- 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 dependencies. 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: juli...@jabber.org Debian: http://www.debian.org/ SPI: http://www.spi-inc.org/ Ubuntu: http://www.ubuntu.com/ FSFE: http://www.fsfe.org/
signature.asc
Description: Digital signature
