[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

On dpkg support for binary recompilations

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

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.

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

Reply to: