On Wed, 2013-04-03 at 20:18:44 +0200, Philipp Kern wrote:
> On Wed, Apr 03, 2013 at 03:33:30PM +0600, Andrey Rahmatullin wrote:
> > On Tue, Apr 02, 2013 at 09:55:09PM +0200, Philipp Kern wrote:
> > > > And not, we do not have epochs to temporarily downgrade a package
> > > > after a botched upload.
> > > c.f. imagemagick
> > > I'm pretty sure we do.
> > It seems "we" usually upload a 2really1 package to fix that particular
> > mistake without introducing an epoch.
>
> Which is a new custom that comes from Ubuntu who cannot reasonably use
> epochs. We can.
Well, I strongly disagree that in general using epochs for packaging
mistakes is a good practice (and I've thought so even before Ubuntu
existed). The main purpose of epochs is to be able to handle mistakes
or changes in the version numbering itself. Say upstream resets their
versioning from v450 to 0.0.0, or from date based 20130404 to 0.0.0
(although the packager could have avoided that by prefixing with "0."),
or if they used something like 1.210 and they meant 1.2.10 (svgalib),
or a package takes over another's name (git).
Epochs are a necessary evil, but they are distracting and clutter the
version string, and if they can be avoided (by way of a 2really1 scheme)
then IMO that should be prefered, beucase that's just temporary, usually
until next Debian release. Also as it can be seen on the archive, once
a version has been tainted (!?), uploaders tend to lower their
resistance to increase the epoch even further.
Also, introducing an epoch where there was none in an NMU should be
frowned upon, unfortunately I've seen multiple instances of these in
the recent past, something I'd be very upset if it happened to any of
the packages I maintain.
Something else I disagree is good practice is bumping an epoch to win
the automatic upgradability against a downstream distribution version
or 3rd-party package repository, because that makes us dependant on
their practices.
Some recentish examples of what _seems_ like gratuituous epoch
introduction (there's probably many others):
audit (NMU upload revert)
clang (NMU upload revert, although with maintainer approval, because
supposedly the package will get merged into llvm, but that
only holds as long as the clang package disappears)
file (NMU upload revert)
fonts-ipafont-nonfree-jisx0208 (just for a tarball repack)
ppl (no clear reason from the changelog?)
usbutils (simply switching from 0.87 to 001 would have been fine)
Not to mention things like fonts-sil-gentium with its date-base epoch.
Something people seem to forget or be unware of, is that binary
packages can contain a different version than the source they come
from, so if you really need to bump the epoch for (say) a shared
library package, you could do it just for that one, which would
disappear when changing package name on the next SOVERSION bump. Or
that when renaming the source and package names the epoch can be reset.
Thanks,
Guillem
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130404180927.ga31...@gaara.hadrons.org
