Proposed MBF: Debian upstream version higher than watch file-reported upstream version
On Sun, 17 Feb 2008, Raphael Geissert wrote:
> Ack, what about only reporting (thus in a non automated way) on those which
> are not affected by any repackaging/similar version part?
It's might be acceptable but I'm not sure either. Some packages have
development version packaged and those development versions are released
differently than the stable releases... thus in theory it would need an
update of the watch file to point to the development release during the
time when the devel version is packaged (AFAIK, that's the case for
glib2.0 that you gave as example).
But as a maintainer I wouldn't update the watch file because what I care
is to not miss a new stable release... missing a development release is
not a big deal.
Maybe there's room for improvement to uscan here. It would check at
several places and know the status (stable, development) of each release
based on where it was found.
At the end, I think there are far better things to do than overoptimize
watch files. If watch files is something that you find important, you could
work on creating watch files for all the packages that don't have any and
submit them (and also use them for DEHS check even while they are not
integrated in the source package).
> > And when we have +svnXXXX we are indeed newer than the upstream released
> > tarball and the information is correct! So stripping that part would be a
> > mistake.
> IMHO it would be better to strip that part with a dversionmangle. However,
> DEHS currently compares with $upstream le $debian so those packages are
> marked as up to date.
I don't know what makes you say better, some aesthetic consideration? In
any case, watch files are not supposed to be a burden to maintain. So I'm
against such modifications.
Le best-seller français mis à jour pour Debian Etch :
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact email@example.com