Jonas Smedegaard <jo...@jones.dk> writes: > Quoting Gard Spreemann (2021-12-02 13:09:17) >> >> Jonas Smedegaard <jo...@jones.dk> writes: >> >> > Quoting Gard Spreemann (2021-12-02 12:31:30) >> >> >> >> Paul Wise <p...@debian.org> writes: >> >> >> >> > I also wonder if it is time to split debian/watch out of Debian >> >> > source packages, since upstream download locations generally >> >> > change independently of the Debian package and so information >> >> > about upstream download locations probably should be maintained >> >> > independently. >> >> >> >> I very much agree. I don't understand the logic of tying upstream >> >> checking to a particular version of a source package. The fact that >> >> some version of a package once upon a time could locate and >> >> download new upstream versions using a particular recipe is of no >> >> use if said recipe becomes outdated at any later time. >> >> >> >> It makes a lot more sense to provide this service in a way that >> >> allows it to be modified/updated/improved/fixed with no regards to >> >> the actual packages that may use it. That could be as simple as a >> >> uscan service with watch files that can be individually and >> >> independently modified. >> > >> > I find it helpful for our packages to include information about >> > where and how (at the time of its release) that package was >> > monitoring for upstream releases. It helps working decentralized - >> > both for preparing packages for Debian and for working on >> > Debian-derived packages, both without needing access to somewhere >> > central for this "watch" information. >> >> Would it make sense for a package to contain a snapshot of the >> relevant metadata in the hypothetical "centralized-and-often-updated >> watch service" at the time in enters into the archives? > > Not _instead_ of current location: What I find helpful is to have the > watch file available with the source package. I am unaware if there > would be some benefit of _additionally_ embedding the watch file in > binary packages (if that's what you meant). > > >> > Therefore I like the proposal to have Debian project scanners >> > aggressively look for _newest_ watch file for a packaging project, >> > including looking up declared Vcs-* hints for not-yet-released work. >> >> Indeed, that sounds like a better idea than what I suggest above! > > Not sure if you noticed, but (since I won't steal credit) I basically > emphasized Pabs' suggestion in last paragraph of what you previously > quoted: > > Quoting Paul Wise (2021-12-02 00:47:44) >> Alternatively, perhaps we could workaround outdated debian/watch files >> by having vcswatch extract debian/watch files from the repo specified >> in the Vcs-* URLs.
Apologies; I somehow thought that he meant auto-generating watch files from *upstream* VCSs. My bad, and thanks for clarifying! -- Gard
signature.asc
Description: PGP signature
