[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


>  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: