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
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
