Unfortunately, this problem turns out to be not as trivial to solve as
first thought. Not from a code point of view, but from an acceptable
implementation point of view.
Having dpkg notice a certain style of postfix (I prefer the "+b1" form)
in the Version of a package and strip that before assigning to
Source-Version seems reasonable in theory. You'd get the following
control information:
Package: banana
Version: 1.0-1+b1
Source: banana (1.0-1)
However it hits an issue with substvars (which aj's patch doesn't
address anyway). Consider the following packages:
Source: banana
Package: banana
Architecture: any
Depends: libbanana0 (= ${Source-Version})
Package: libbanana0
Architecture: any
Depends: libbanana-common (= ${Source-Version})
Package: libbanana-common
Architecture: all
This would produce the following relationships after a
binary-recompilation, without worrying about substvars:
banana_1.0-1+b1 -> libbanana0_1.0-1+b1
libbanana0_1.0-1+b1 -> libbanana-common_1.0-1+b1
However this libbanana-common package is arch:all, so would either break
existing dependencies in the archive, or if not included cause the
current dependencies to fail.
We could address substvars by ensuring ${Source-Version} is the version
of the source, not the binary, and we therefore get:
banana_1.0-1+b1 -> libbanana0_1.0-1
libbanana0_1.0-1+b1 -> libbanana-common_1.0-1
Now it's the libbanana0 dependency thats broken, we're depending on a
version that's just been out-dated by the binary recompilation.
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.
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} .
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 other option is to extend the current version-comparison routine and
add a "ignored suffix" to it, kinda like a "recompilation epoch". I'm
going to randomly suggest the following:
1.0-1@1, 1.0-1@2...
When performing version comparisons, dpkg and apt would simply ignore
anything after the @ symbol and treat both of these versions as
identical.
Therefore your binary recompilation would be able to depend on either
1.0-1 or 1.0-1@1 with the same effect.
This has a problem as well that it would mean none of the tools
(including katie) would know which version supersedes the other. We'd
have to do something a bit more clever.
The recompilation epoch would only ignored when used in dependency
fields; when used in other version comparisons it should still be
included. This would make life harder for tool developers, as they'd
need to know *why* they were comparing versions, rather than just
comparing them.
Scott
--
Have you ever, ever felt like this?
Had strange things happen? Are you going round the twist?
Attachment:
signature.asc
Description: This is a digitally signed message part