Re: On dpkg support for binary recompilations
Scott James Remnant wrote:
Source: banana
Package: banana
Architecture: any
Depends: libbanana0 (= ${Source-Version})
Package: libbanana0
Architecture: any
Depends: libbanana-common (= ${Source-Version})
Package: libbanana-common
Architecture: all
Any packages that do that are already broken for binNMUs -- since
banana/$ARCH will depend on the wrong version of libbanana0/$ARCH. So I
don't think this is an issue.
We could address substvars by ensuring ${Source-Version} is the version
of the source, not the binary, and we therefore get: [...]
The binary version is available in the ${Version} substvar, developers
would have to be extremely careful to ensure that dependencies on
arch-any packages are done with ${Version} and arch-all packages with
${Source-Version}; and that they only do binary-arch when preforming
binary recompilations.
That seems straightforward to me...
This is in breach of current policy (§ 8.5) which says library
development packages should have an exact version dependency on an
arch-any package using ${Source-Version} .
Err, policy says "The ${Source-Version} subsitution variable can be
useful for this purpose" -- it's not a policy violation if it turns out
something else is more useful. It also doesn't say it must/should have
an exact dependency, just that it typically does.
So this would require a policy change, and an extraordinary amount of
care by both the original developers and binary recompilers. I doubt
most people would get it right, leaving us with the same problems we
have today.
The only problem we have today is that you have to use heuristics to
work out what binary versions match what source versions...
Cheers,
aj
Reply to: