Re: Debian part of a version number when epoch is bumped
On Mon, 02 Apr 2018 at 20:30:54 +0200, Christian T. Steigies wrote:
> I don't understand why everybody is so afraid of an epoch, but ok.
It's a source of confusion (and confusing side-effects) that, once added,
can never be removed, however many upstream releases might happen.
> On Fri, Mar 30, 2018 at 02:21:43PM +0300, Adrian Bunk wrote:
> > The second problem is about filename overlap after incorrect epoch usage.
>
> So the epoch is not really part of the version number, it is just there for
> "sorting"?
Sort of. It appears in the form of the version number that's in most
places, but not in canonical filenames. Conceptually, it's part of the
Debian package version but not part of the upstream version.
> > What can be done for moon-buggy is to use a Debian revision that doesn't
> > result in filenames that are duplicates with pre-epoch packages.
>
> So what should I have done intially and what should I do now?
>
> I should have uploaded the package as 1.0.51-12 even though I uploaded a
> (new) orig.tar.gz?
A recap of what happened, for those who might have lost track:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887740#10
> The old source package contained two tar
> balls, the "real" tarball plus a separate one with patches (upstream wanted
> things separate). The build script was, say, not optimal, and I also made
> the mistake of uploading it as debian native package. By bumping the epoch
> and repackaging from scratch, I tried to fix all the mistakes I had made a
> long time ago.
The newest version of the old tar-in-tar packaging can be seen here:
https://sources.debian.org/src/moon-buggy/1.0.51-11/
What I would personally have done *then*, from that starting point, would
be to bump the version to 1.0.51+repack, or maybe 1.0.51+upstream if
the new orig tarball was something that the upstream developer released,
or something similar, then package and upload revision 1 of that. That
would have been fine - no epoch needed.
However, because you previously maintained this as a native package,
there has been no collision for the filename of the orig.tar.gz, because
before the epoch was added there *was* no orig.tar.gz; and you've already
paid the maintenance cost of having an epoch, so you might as well benefit
from it. So what I'd advise *now* would be to increase the revision to 12
and carry on from there.
smcv
Reply to: