Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Mon, Apr 01, 2013 at 01:13:29PM +0100, Neil Williams wrote:
> On Mon, 1 Apr 2013 17:42:29 +0600
> Andrey Rahmatullin <email@example.com> wrote:
> > On Mon, Apr 01, 2013 at 12:33:15AM -0500, Steve M. Robbins wrote:
> > > > Thanks for trading the R release cycle with Debian's and for
> > > > delaying the release. The harm has already been done, so somebody
> > > > should probably go and create a transition tracker for it?
> > >
> > > Rather than accept the harm, surely the release team could simply roll
> > > back the upload in some manner?
> > Only by uploading older versions with bumped version numbers, and that
> > still will cause testing and unstable to have different binaries.
> That is why we have epochs - an epoch is ignored for the purposes of
> the binary packages, see zlib1g and other packages using epochs. The
> existing tools have sane support for epochs, exactly to avoid these
> dpkg -l | grep ':'
> The version currently in wheezy could be re-uploaded with a single
> change to the changelog to start using an epoch and using the version
> string currently in wheezy for the post-epoch string of the new version.
> If wheezy had foo 1.2.3-1 and unstable 2.0.0-1, the epoch version of
> 1.2.3 would be 1:1.2.3-1 which is newer than 2.0.0-1 but be compatible
> with 1.2.3-1 already in wheezy.
Actually that hits another problem. Namely that the epoch does not
appear in the binary package filename. While wheezy would have 1.2.3-1
and unstable would have 1:1.2.3-1 they both produce the same
foo_1.2.3-1_amd64.deb. But for certain the file contents will differ,
the files won't be bit identical and checksums will differ. The
archive can not handle that case.
You would have to upload foo 1:1.2.3-2 to avoid the name clash.
And not, we do not have epochs to temporarily downgrade a package
after a botched upload. Esspecially when the package doesn't yet have