On Mon, Apr 02, 2018 at 08:30:54PM +0200, Christian T. Steigies wrote:
> Moin,
Hi,
> On Fri, Mar 30, 2018 at 02:21:43PM +0300, Adrian Bunk wrote:
> >
> > There are two problems here.
> >
> > The first is the use of an epoch in a situation where it shouldn't be used.
> >
> > The actual "trap" is when a maintainer used an epoch in such a situation.
> >
> > Once introduced in a package an epoch cannot ever be undone, so all that
> > can be done on that is to make it clearer that it is wrong to use an
> > epoch in such cases.
>
> I don't understand why everybody is so afraid of an epoch, but ok.
not really afraid. "optically not nice", "slightly confusing" and
"irreversible" are the words I would use.
> > 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"?
It is somehow part of the version number, but not in the filenames.
This is not a problem when an epoch is used for a change in the upstream
version numbering scheme.
> > It is important to understand that this is only relevant for cases where
> > an epoch was used where it shouldn't have been:
> > When an epoch is used as intended for a change in the upstream version
> > numbering scheme (e.g. from 20171224 to 1.0), there is no overlap in
> > version numbers.
> >
> > Launchpad gave an error on that, and this is better than the silent
> > breakage in Debian of the assumption that no filename is ever used twice
> > in Debian. I would consider it a bug in dak that it doesn't know about
> > all versions and filenames that ever existed in Debian.
>
> ok
>
> > It would be wrong to document in Debian policy that skipping Debian
> > revisions is required in such cases, since the only case where this
> > second problem can happen is when a maintainer used an epoch in a
> > situation where it shouldn't be used (first problem).[1]
> >
> > For the future it should be documented better that using an epoch is
> > wrong in such cases, but for past incorrect epoch usage all that can
> > be done is to limit the damage.
>
> If this can't go into policy, then I hope it will go into the wiki or a
> packaging best-practices or so.
>
> > Things that cannot be undone for moon-buggy:
> > - the epoch
> > - two files moon-buggy_1.0.51-1.dsc exist in Debian,
> > with different contents [2]
> >
> > 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?
Yes.
As far as I understand it a mistake happened back in 2006 when a new
upstream version was uploaded as .tar.gz instead of .orig.tar.gz and
.diff.gz.
Correcting this mistake was correct, but it did not require an epoch.
> Now I should upload it as 1:1.0.51-12 and be done with it?
I don't see a reason for touching the 1:1.0.51-1 changelog entry,
files like moon-buggy_1.0.51-1.dsc or moon-buggy_1.0.51-1_amd64.deb
are no longer unique in the history of Debian and this cannot be
undone.
Uploading with a new changelog entry for 1:1.0.51-12 added on top
of the current 1:1.0.51-1 entry is the best option.
> No renaming of the orig.tar to 1.0.51+really1.0.51 neccessary?
This is not necessary, unless I miss something there was never before
a (different) moon-buggy_1.0.51.orig.tar.gz in Debian.
> thanks,
> Christian
Thanks
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
