On Thu, Apr 30, 2009 at 10:40:41PM +0200, Giacomo Catenazzi wrote: > James Vega wrote: > > On Thu, Apr 30, 2009 at 07:24:59PM +0200, Giacomo Catenazzi wrote: > >> James Vega wrote: > >>> On Thu, Apr 30, 2009 at 03:16:44PM +0200, Giacomo A. Catenazzi wrote: > >>>> I find no official documentation on format of debian/watch files. > >>> man uscan > >> > >> I mean in policy or reference or such official docs. > > > > Why should it be duplicated there? debian/watch is a file that exists > > because of uscan, so uscan should be what documents the format. > > not duplicate, but a reference to uscan, specifying the formats. > BTW policy doesn't reference to uscan, but to other tools, so > uscan is also not the definitive answer. Yes, policy does reference uscan in the section that discusses debian/watch. > >> Now it is a generic convenience (for maintaner) file. > >> These is also no dependencies on uscan version in debian/control, > >> and often no scripts in debian/ refers to uscan. > > > > Why would uscan be mentioned at all in debian/control? It's not used > > during the build process. No scripts in debian/ need to refer to uscan. > > > >> For this reason, it is also hard to define bugs on debian/watch files. > > > > Why? Either the watch file is written in the proper format so uscan can > > parse it and perform the requested actions or it isn't. Anything other > > than that would fall into the territory of uscan behavior. > > if uscan is not called within the package (build or runtime), it is > outside packaging, so what kind of bug can he have? > it is not a policy violation, it is not a file installed on user machine, > it is not used on building package. > What kind of bug is it? (it was a question on the my first mail) It's a bug in the source package. > >> Feel free to standardize it by putting some more references in > >> debian policy. > > > > Any tool that a developer may use in the process of maintaining packages > > which leaves a file in debian/ now has to be documented in policy? > > No, but this is the main point! > If my uscan works with my debian/watch, why do you bug my debian/watch. > See? We're talking about debian/watch files using obsolete formats, for which Raphael would like to remove support. This simplifies uscan's code, makes it easier to maintain, and makes it eaiser to split the watchfile parsing logic out into its own module. The last point would then allow tools like Lintian to perform checks on the watchfile that aren't guesses but actually use the same parsing code as does uscan. > Without a proper reference, debian/watch is a developer file like others, > thus only developer can tell if it is correct or no. It has a proper reference. The specification of the file format in uscan(1). > But debian/watch is not used only for uscan, and now it is a important > tool for quality checks, Tools which currently invoke uscan, thus uscan is still the only tool to consume debian/watch. > so I think we should upgrade the status of debian/watch, prescribing a > valid formats We already have valid formats documented. > Note: Yet uscan is like lint, it only check sources. It is nice not to > have errors, but do you bug mass every package that fail with lint? > No. Do you bug package that has a wrong syntax in debian/control? Yes! > See? uscan and lint aren't related tools. If a developer has bothered creating debian/watch, then its purpose is to be used with uscan to check for new upstream versions. If that doesn't work, then there is a bug in their source package. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega <jamessan@debian.org>
Attachment:
signature.asc
Description: Digital signature