Raphael Hertzog wrote: > 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.
You can specify several urls on a same watch file, e.g.: 8<---->8 version=3 http://domain.tld/downloads/foo-(.*)\.tar\.gz opts=uversionmangle=s/beta/~beta/ \ http://domain.tld/downloads/pre/foo-(.*)\.tar\.gz 8<---->8 > > 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). DEHS already does its best to guess watch files by using the urls provided in the copyright files of the packages. Those are the so called 'watch wizard-generated watch files' and their result does appear on DEHS and on the DDPO. For the last part you mention it sounds more like one of the features that is already mentioned in[1]. > >> > 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. So both versions match. But at least any Debian-related repackaging should at least be removed from the Debian version with a dversionmangle since both (with dfsg, without dfsg) are the same version. > > Cheers, [1]http://wiki.debian.org/DEHS Cheers, Raphael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
