Re: multiarch: dependency-oriented vs package-oriented
Discussions should probably go to debian-dpkg.
"Eugene V. Lyubimkin" <jackyf.devel@gmail.com> writes:
> Hi Goswin, hi -devel,
>
> I would somewhat object to Multi-Arch field in the long run, and here are my
> thoughts.
>
> What the multiarch spec proposes now is package-oriented approach: the package
> should define whether it is 'same' or 'foreign' kind. This is not
> straightforward, because in fact not the package decides it's multiarch
> 'role', but its reverse dependencies. Only they 'decide' they want to
> arch-dependent package 'functionality' or arch-independent one. From the
> package manager PoV (dpkg and its frontends) I find dependency-oriented
> multiarch info is more clearer and easier to implement.
For most things the depended on package decided what its interface
is. Wether it provides a command line interface (sed) or a binary
interface (libfoo.so.X) to the world. This is usually clear cut.
The reason why we want to define this in the depended on package is
threefold:
1) Many packages depend on a few libraries. If we tag the few
libraries all the depending packages become installable. Less work.
2) Tagging package relationships instead of packages means extending
the syntax of package relationsships, trusting the binary packages to
get the depends right (and those are manual depends apart from libs)
and making package relationships in every package longer. Packages
files are HUGE already:
-rw-r--r-- 1 root root 27M Jul 24 18:35 /var/lib/apt/lists/chocos_debian_dists_sid_main_binary-amd64_Packages
3) 3rd party packages are verry hard to change. Lets face it, on amd64
a major reason for doing this is to get those 3rd party products
running that still haven't managed to build 64bit versions. Getting
them to tag their packages and tag them right would take forever. It
is way to easy for them to tag something wrong.
But there is another reason, a reason why we must:
A library package must say if it is coinstallable for multiple
architectures or not. Must say if it was multiarchified or not. Just
because some package depends on a libary with some "same architecture"
flags in no way means that library is multiarchified. So we need every
library package to say "Multi-Arch: same" when it has moved its
library files to /usr/lib/$(DEB_HOST_GNU_TYPE). Why should we not use
that information also for package relationships as well? Adding the
"same" flag in both the library and the depends seems stupid.
Without the flag in each library it would be way to easy for packages
to screw the system and multiarchifying would have to be in strict
order of dependencies, with lots of transitions and lots of versioned
depends and so on. Verry ugly.
And if we have "Multi-Arch: same" then also doing "Multi-Arch:
foreign" seems logical. No point in manually flagging package
relationships on binaries but autodetect package relationships on
libraries. I rather flag one binary package than 500 reverse depends
on it. The problem cases really are the exception (ignoring the -dbg
packages below, that should use magic in the package managers). A mere
handfull out of 20k packages.
> Goswin, as you are already noted, the packages which are known to have both
> kind of dependencies - at least, some interpreters - have nothing to do with
> that Multi-Arch field, and to handle them, you'll have to put this info in the
> package that is dependent on this interpreter in the long run.
>
> Moreover, this is not the only exception. Thousands of desktop and server
> packages that contains executable binaries (applications) compiled from
> C/C++/Pascal/etc. also have arch-dependent reverse dependencies - packages
> with debug info, '-dbg' ones. So, they are not 'Multi-Arch: foreign' too. With
> 'arch:all' packages being not a problem at all fortunately, there are only one
> (?) kind of packages left with meaningful Multi-Arch fields - arch-dependent
> library packages for compiled languages which are always multiarch 'same', but
> they also already special-cased/handled by various tools like dpkg-shlibdeps,
> dpkg-genshlibs, and it would been possible to even generate runtime
> dependencies ({shlibs:Depends}) with proper multiarch dependency info without
> even bothering the maintainer to do it.
You raise an interesting point there with -dbg packages. Esspecially
considering the Google SoC project that wants to automatically build
-dbg packages for everything in debian. Those .ddeb packages. Too me
it seems that .ddeb packages seem like a really good idea and teaching
the package management system that .ddeb packages must match the
architecture no matter what the .deb says seems like the solution to
your example. The -dbg packages could be handled all in one go
magically. So do you have another example besides -dbg packages?
I myself am not yet happy with the "Multi-Arch: allowed" feature as
solution. And I haven't heard all the rational behind it. Why it is
better than other suggestions from the past. It is something that has
been added to the specs recently and I think you make a point that
maybe it needs to be thought of or explained some more. The existing
-dbg packages certainly make a point for allowing "Depends: foo:same"
or "Depends: foo:arch" no matter what foo has as "Multi-Arch: ...".
Or maybe -dbg could say "Multi-Arch: force-depends" overriding what
the depended on package says. The advantage of the last would be that
it would not require a dpkg transition. But it only works well with
-dbg packages as they only depend on exactly their striped counterpart.
Another option would be for foo to
Provides: foo-$(DEB_HOST_GNU_TYPE)-${binary:version}
and for foo-dbg to depend on that. Or for plugins
Provides: foo-$(DEB_HOST_GNU_TYPE)-$(PLUGIN_ABI).
So maybe back to the drawing board for "Multi-Arch: allowed"?
Note that for current use cases, things people use biarch for, there
is I think only pam, pango, gtk and qt with plugin issues. All of
those are libraries and will have "Multi-Arch: same". I agree the -dbg
packages have to be handled in some way in the first round. Doesn't
have to be the final way, just has to prevent breaking things. But
delaying the rest of problem packages to work multiarchified to a
second round after a stable release would still allow 99% of use cases
to be happy. So lets do this in increments.
> For the upgrade path, we can stick default multiarch 'same' to the all
> packages in archive, so implementing multiarch support won't broke anything at
> all at all without changing nor source not binary packages at this moment, and
> the maintainers are free to bother ourselves to mark some dependencies as
> multiarch 'same' to allow foreign dependencies to be satisfied with less
> number of packages in the system in the long run.
Arch: all packages are considered "foreign" and I think you ment
that. Arch: all packages are considered to be really for all
architectures when it comes to installing. Although that is not true
for the sake of package relationships when you look at it
recursively. Look at transitional dummy packages. Consider
"libfoo1:all depends libbar2:any" and "baz:all depends buzz:any" (buzz
being a binary). libbar2 must have the same arch but buzz can have any
arch for packages depending on libfoo1 and baz.
But that is something for the implementation in dpkg/apt and not
something maintainers have to worry about. dpkg and apt will sort out
Arch: all packages automatically.
MfG
Goswin
Reply to: