Re: Question about watch-file
On Tue, Jul 08, 2008 at 11:23:24PM +1000, Ben Finney wrote:
> Right. And the lintian message suggests exactly what I'm suggesting: a
> watch file that documents exactly why 'uscan' can't yet do its work
> for this particular package.
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
inappropriate.
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.
> Indeed. Documenting them explicitly is what I'm suggesting, instead of
> an override to silence a message.
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.
> Creating the watch file with comments on the *current* situation is no
> barrier to also working with upstream to fix that situation. In
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.
> addition, it documents the current situation exactly where people can
> be expected to look, for as long as that situation persists.
Where people can be expected to look if they already decided to fix a
certain package, yes. But their is a chance that somebody wants to fix
different packages that have similar problems, for example. The problem
is hidden from them.
I'd be interested to hear other opinions about this. Obvious these are
just my 2 cents, above.
Best Regards,
Patrick
Reply to: