On Wed, Jan 24, 2018 at 07:39:24PM -0500, Jeremy Bicha wrote: > On Wed, Jan 24, 2018 at 3:05 PM, Christian T. Steigies <c...@debian.org> > wrote: > > The bug report you mention has had no activity since more than a year, so I > > guess this is not seen as a problem. If it were a problem, the upload > > should have been rejected and not progressed into testing. > > If we were able to auto-reject every bug, then there wouldn't be any > bugs in Debian, right?
Isn't that the goal? This will probably never happen, but at least wrong version numbers should be automatically detectable, by lintian or other tools that ftp masters use. If I can not use an epoch to start version numbers from scratch, then the whole implementation of epochs is broken. I doubt that I am the first to fall into this trap. > Epochs are bumped so rarely that I guess no one thought this issue > needed to be written into Debian Policy yet. Should we ask other > Debian Developers what they think about this issue? I think we can agree that this is a bug not specific to my package. I think it is a ubuntu bug, so you should forward it to ubuntu. You think it is a debian bug, in that case I think you should attach it to the bug you already mentioned. If you do not agree to that, maybe you have to take it up with the TC, as I do not plan to introduce a bug in debian packaging to fix a bug in ubuntu. Or you take over maintenance of the package, but I doubt that this would make the bug go away. > > So you agree that this is a bug in Launchpad that it does not handle epochs > > correctly? > > No, it will cause problems for any system that maintains a complete > Debian package history which absolutely should be possible. But you showed me that snapshot.debian.org has absolutely no problem to keep track of every single upload by using separate directories that include the epoch in the directory name. Or is this a bug as well? > > You did not look at the files it seems. > > 1.0.51-11 contains moon-buggy_1.0.51-11.tar.gz > Switching to 3.0 (quilt) gives you moon-buggy_1.0.51.orig.tar.gz > > Those file names are not the same and therefore it would have been > fine. You absolutely do not need an epoch when switching from a native > package to a non-native package. But I can not upload two 1.0.51 versions with different tar files, can I? > > I saw no other way to use the actual orig.tar.gz than using an epoch. > > You could have used a 1.0.51+repack-1 version number, which would have > worked just fine for Ubuntu too. But it would have been wrong because I uploaded the actual orig.tar.gz, it was not repacked. Maybe the earlier uploads should have used repack as I had to merge two upstream tarballs into one, but that would not have allowed me to go back to the actual orig.tar without an epoch either. I waited for a new upstream version for a long time, but with the removal of esound support I had to do something now (and upstream indicated that there would be no further development, especially no more sound support). Christian
