[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: uscan roadmap



Jonas Smedegaard <jonas@jones.dk> writes:

> Quoting Gard Spreemann (2021-12-02 13:09:17)
>> 
>> Jonas Smedegaard <jonas@jones.dk> writes:
>> 
>> > Quoting Gard Spreemann (2021-12-02 12:31:30)
>> >> 
>> >> Paul Wise <pabs@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
 

Attachment: signature.asc
Description: PGP signature


Reply to: