* Julian Andres Klode [Thu, 15 Jan 2009 15:07:55 +0100]: Hello, Julian.
> 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 > -------- > 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. Well... > 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. This disadvantage is not a disadvantage, but a sign that this proposal of yours is solving a *different* problem. What you want is arch-specific Dependencies to work for arch:all packages. That *is* a worthwile goal IMHO, but a different one. And it's indeed not backwards compatible, and requires changes in the dpkg/apt/... toolchain. What Neil and me are interested is in not letting uninstallable arch:all packages tricle into the Packages files. (He wants it to make the archive from Embdebian smaller; I may want it because it may improve user experience.) Do you see that? If so, let's continue. (If not, here's a further hint: how does option #2 differentiate between "arch:all pkg1 can't work on i386 and amd64 without pkg x, but is fine elsewhere without it" vs "arch:all pkg2 depends on z, and can't function without it, but z is only available on on i386 and amd64"). > 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. Programs creating repositories will need to be changed *no matter what approach you take*, since the idea is precisely to modify their behavior. They may have to be modified to grok "Architecture: all [i386 amd64]", or Install-Architecture, or a file. (This is also why, btw, I don't get Neil's wish for a "generic solution". Every solution is going to need modifications everywhere one wants it implemented.) But I already said in my other mail that a P-a-s like approach may not be the best option, given the size of the problem. (Neil, I'm surprised you haven't meet "P-a-s": http://buildd.debian.org/quinn-diff/Packages-arch-specific.) Still, I don't agree with your final bits of reasoning: > 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. (As said above, option #2 solves an orthogonal problem.) > 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. What you are suggesting here is that apt and dpkg should refuse to install an arch:all package if its control field says it's not supported in that architecture. And I say that's bollocks^Wnot a reasonable thing to do. An arch:all package should be installable anywhere where its dependencies can be satisfied. And if they can't be satisfied, dpkg/apt will refuse to install it already. No, the only use for "Architecture: all [i386 amd64]" or "Install-Architecture: i368 amd64" would be as a hint to dak (and other tools) that the package is known not to be installable anywhere else, and hence should not be put in other Packages.gz files. That's *all* that matters AIUI. > 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. #2 is orthogonal, and I see no benefits of #1 over #3, given my reasoning above that dpkg/apt have nothing to do with it (hence you'd be adding support in them for something they are not going to use). But I'm still very unconvinced that debian/control is the right place to put this information. And ftpmaster should be involved in this discussion anyway, and more people as well. P.S.: May I ask, that lines in your mails don't get much longer than 72 characters? TIA. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Radiohead - House Of Cards -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
