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 :)
>
> 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.
> 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?
> 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.
>
> 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).
> 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.
> 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
>> 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.
> 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.
>
> 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.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Maintainer
Attachment:
signature.asc
Description: OpenPGP digital signature