Re: Arch:all package depending on package that isn't Arch:any
* 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
Reply to: