Re: Question about watch-file
Patrick Schoenfeld <email@example.com> writes:
> Seems wrong to me. The lintian text states that a package which is
> "(...) not maintained upstream (...)" may add a commented watch file
> "(...) containing only comments to document this."
> In my opinion the wording is very clear and aims at packages who are not
> maintained upstream. Meaning that a watch file is useless, because it
> will never report new upstream versions. But a comment is useful,
> because everyone who wants to do something with the package can read
> from it that upstream is dead. Despite that I'm not sure if the watch
> file is the proper place for such a note this has sureley an
> entitlement, and the watch file can't be fixed anyway, so a warning is
> But this case is different. This case has a more or less active upstream
> (or did I get something wrong?) with broken distribution tarball names.
> It breaks watch file support, because uscan is not *able* to detect
> upstream versions.
I've changed the Lintian text to make it more explicit that Lintian is
intending to recommend a watch file containing only comments for cases
This source package is not Debian-native but it does not have a
debian/watch file. This file is used for automatic detection of new
upstream versions by the Debian External Health Status project and
other project infrastructure. If this package is maintained upstream,
please consider adding a debian/watch file to detect new releases.
If the package is not maintained upstream or if upstream uses a
distribution mechanism that cannot be meaningfully monitored by uscan
and the Debian External Health Status project, please consider adding
a debian/watch file containing only comments documenting the
Lintian's purpose here is to encourage people to add watch files where
they're useful. Since Lintian has no way of knowing whether or not such a
watch file could be useful, and neither do systems that use the watch
files, it encourages including a watch file containing only comments to
disambiguate between the case of no useful upstream that can be monitored
and the case of a maintainer who's just never thought about a watch file
at all. We want to do different things as a project in those two
situations, and if both are represented by having no watch file, there's
no way to distinguish.
> Well, the problem with your solution is that you silence an indicator
> for a problem anyway. Someone who looks at the lintian status of the
> package can do this from the outside and can decide to act upon. If you
> add a comment in a watch file then you have a comment in a hidden place
> for a lot of people who could potential fix the problem. They would need
> to look *into* that specific package, which is unlikely.
This is a problem that can be easily fixed if desired by, for instance,
having the Debian External Health Status system extract watch files
containing only comments and put the text of the comments up on the DEHS
> No, not for the current maintainer, thats true. But it *is* a barrier
> for everybody who wants to track specific problems from the outside,
> e.g. by looking at lintian.d.o.
This is not a problem *with the Debian package*, which is what lintian.d.o
is trying to track. It's a problem with upstream. We have a few Lintian
tags that represent upstream bugs about which the Debian maintainer can do
nothing except bug upstream, but I'm not horribly happy with them and
having more of them is generally not useful. Ideally, the lintian.d.o
report for a package should represent some sort of meaningful to-do list
for the Debian maintainer. Including things on that list that aren't
actionable works against that purpose.
Russ Allbery (firstname.lastname@example.org) <http://www.eyrie.org/~eagle/>