Re: multiarch: dependency-oriented vs package-oriented
Steve Langasek <vorlon@debian.org> writes:
> On Wed, Jul 29, 2009 at 11:20:20PM +0200, Goswin von Brederlow wrote:
>> 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?
>
> In the specific case of external .ddeb packages, there are additional
> options available to us. In particular, since .ddeb archives don't exist
> today for Debian, and would presumably not be subject to the same sort of
> archive consistency checks, then if dpkg adds support for
> architecture-constrained dependencies (Depends: fwibble:i386) in the squeeze
> time frame, these could be used for ddebs immediately in squeeze even though
> they're not supported in the main archive.
And with .ddebs being a release goal (if I read the latest
announcement right) I consider the -dbg packages covered.
>> 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: ...".
>
> Which past suggestions are you referring to? Ephemeral ideas that no one
> saw fit to record aren't of much help.
>
> I think the rationale is already laid out in the spec.
For example why "Multi-Arch: allowed" and "Depends: python:any"
instead of "Depends: python:amd64"? The 'any' case means ~2500 perl
depending packages need to specify it. The 'amd64' case would only
need plugins to specify it.
If one looks closely then right at the end you have "Permit flag days
for interpreters, reducing the number of packages to touch", which
covers this case I think. It would be nice if such rationals would be
linked directly to the parts of the proposal they affect.
> I also think that -dbg packages are a wart on our archive and our packaging,
> and am not overly concerned about whether these packages remain consistent
> on transition to multiarch - unlike interpreters, which need to be handled
> right for the sanity of our users.
>
>> 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).
>
> I don't think that's acceptable.
Then that could also be linked as background information as to why
"allowed" is used. Might be good to document what has been ruled out
as unacceptable so people don't come with the same idea next month.
And I do mean linked as in to a seperate document. All the not choosen
paths don't need to be on the specs itself.
MfG
Goswin
Reply to: