Re: multiarch: dependency-oriented vs package-oriented
"Eugene V. Lyubimkin" <jackyf.devel@gmail.com> writes:
> Goswin von Brederlow wrote:
>> "Eugene V. Lyubimkin" <jackyf.devel@gmail.com> writes:
>>> 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.
> Hm, no, not for all. Again, amarok-dbg depends on amarok in arch-dependent
> way. And some others. Yes, no one provided sed-dbg yet :)
<self>-dbg is not the world. :)
>> 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.
> Keeping existing relationships with existing syntax as 'multiarch:same' become
> installable all packages. Without any work. Well, with all the dependency
> tree, but for that libraries it's anyway the same case.
No, that just plain makes every package cause an override
conflict. That is the difference between no Multi-Arch field and
same. Same means packages are coinstallable. Apart from that no
Multi-Arch and same behave the same.
The Multi-Arch: same actualy is an improvement to your
suggestion. YOur suggestion is already in the specs for when no
Multi-Arch is specified.
>> 2) Tagging package relationships instead of packages means extending
>> the syntax of package relationsships, trusting the binary packages to
>> get the depends right
> You'll have to do it sooner or later. At least for already mentioned perl,
> python and others. Or no?
Yes, but how many are there. Perl for example has 2627 reverse
depends. How many of those are plugins?
>> 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
> Well, "Multi-Arch: <value>" would also make Packages longer.
But only one entry per package, not one entry per package
relation. Say a library has only 2 reverse depends. Tagging both with
":kfreebsd-amd64" will be longer than "Multi-Arch: same". And
libraries and binaries have a lot more reverse depends.
>> 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.
> Same answer as for 1).
No. Most 3rd party debs are leaf packages/cluster. Nothing needs to
happen there. Imagine packages as a tree sorted by dependencies. We
only need to tag the root but the far bigger crown can stay as
is. As mentioned before there are less than 200 packages in use in
biarch now.
>> 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?
> Because, hm, this is different kind of info.
>
>> Adding the
>> "same" flag in both the library and the depends seems stupid.
> Got it. I would still propose 'Multi-Arch: yes' only for mentioned purposes
> (co-installability) and dependencies for others. But yes, this makes my point
> more weak.
Yeah, the earlier drafts did have yes/no but at that meeting the Ubuntu
draft was worded they somehow decided on same/foreign.
>> on it. The problem cases really are the exception (ignoring the -dbg
>> packages below, that should use magic in the package managers
> mm? is it a part of a plan? urh, ugly
Not yet.
>>> 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?
> No, I noted all examples came to my find for now. I supposed that so major
> architecture change should care about every and all packages.
Only in the sense that multiarch will not allow you to install
something that doesn't work. Esspecially in the first round it is
perfectly fine if some things are not installable in all configuration
as long as they are installable with only native packages. The -dev
packages will fall under that group in an effort to keep the first
round small.
>> 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
> ^^^^ here should be 'foreign', of course
>>> 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.
> I assume the correct approach would be "libfoo1:all depends libbar2:same" then
> in my view. But must I admit I'm a bit lost with current mixed proposal and
> find it not very intuitive.
I did draw some graphs about all the different package relationships
because I couldn't keep them all straight myself. Unfortunaetly I was
traveling and my battery was dead so I did it on dead wood. I guess I
should transefere them to bits and ask them to be included in the
proposal.
>> 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.
> I will have to implement this in libcupt too when it's get accepted, so I'm
> also interested.
Then you will also have to deal with all the implicit conflicts and
replaces. E.g. foo:all conflicts/replaces with any foo:<arch>.
Yeah, time to input the graphs I did. Much easier to see this in a
picture.
MfG
Goswin
Reply to: