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:
>>
>>> Goswin von Brederlow wrote:
>>>> "Eugene V. Lyubimkin" <jackyf.devel@gmail.com> writes:
>>>>>> 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?
>>> Don't matter. If even there is literally one package, the new syntax has to be
>>> defined. Once you add it, it doesn't matter - one package uses it or thousand
>>> of ones.
>>
>> Sure. But do you want to alter 10 plugin packages or 2627 packages?
>> Considering how hard it is to transition has gone into the
>> considerations too.
> The best I would imagine is to alter 'Arch: any' to 'Arch: multi' (as
You can be "Arch: amd64 i386" and still be "Multi-Arch: same" or
"Multi-Arch: foreign". The two fields are completly independent other
than the arch: all case. "Arch: multi" really won't work.
> Charles suggested) or insert 'Multi-Arch: yes' automatically by the some
> tool (dak?), as checking co-installableness can be done automatically by
> simply diffing 'dpkg -c package.deb' for produced arches (one and tricky
> way), or add them manually to the ~200 libraries you want to transition
> in the first round - not very hard. For thousand of Perl libraries
The flag needs to be in the packages DEBIAN/control or various tools
would have to duplicate the automatic magic and I really don't want
DAK to mess with uploaded debs. The only palce for this would be
during build, which means dpkg-gencontrol logically. Detecting
packages that should have "Multi-Arch: same" could probably be done
savely that way. But not "Multi-Arch: foreign" as there are two many
cases where "Multi-Arch: foreign" is not appropriate (yet) even if the
package has no libraries. So you would only cover some packages.
Add to that that library package have to adjust their libdir then
asking them to add one line to debian/control as well is really no
extra work.
> inserting 'Depends: perl:foreign' could be inserted by ${perl:Depends}
> substitute requiring binNMUs only. I am not sure for python modules or
> modules for other interpreters though.
How will ${perl:Depends} know when there are only scripts in the
package and when plugins? Figure that out and by all means make
dh_perl capable of setting the depends right automatically.
But not everything is using debhelper. The specs only lay out the
changes that need to be done in the resulting deb. Not who has to make
those changes. Things like debhelper and cdbs will hopefully automate
some things. I could imagine that you could have the following rules
file:
#!/usr/bin/make
%:
dh --with multiarch $@
or at some point --with multiarch would be default.
> I would still want that multi-arch dependencies would be specified at
> one straight place, not two.
For most things it will be the depended on package. Your suggestion
would make it always be in 2 places (co-installability in the library,
depends in the dependee). I think the proposed way and having it in
90-99% only in the depended on package is better.
MfG
Goswin
Reply to: