On Monday 01 May 2006 05:24, Jeremy Stanley wrote: > On Mon, May 01, 2006 at 01:01:43AM +0300, George Danchev wrote: > [...] > > > Right. These are all good reasons to start hacking around ;-) but now I > > can think of some troubles for autobuilder in case of upstream sites not > > accesible at the package build time or incomplete/changes downloads being > > cought by the get-orig-source target or dpatch-get-origtargz script. This > > will result to more human actions and generally should have a broader > > discussion for its merits imho. > > Oh, I heartily agree that expecting the archive autobuilders to > download upstream source would be a nightmare. I was thinking more > along the lines of allowing sponsors or developer end-users to > easily check and/or recreate the packages. Not that things like the > *BSD ports don't break visibly for users when an upstream site > becomes unavailable or rearranges its downloads pages, but that's > just one more reason I use Debian as my primary operating system.
Good, we agree that the primary user base of the get-orig-source should be human objects, not deamons. No other targets might depend on it also since they should be invokeable by non-humans ;-) > What I was trying to get at is that, with proper implementation, it > might be possible to integrate the get-orig-source target in > debian/rules a little more tightly with the origin information in > debian/copyright and version in debian/changelog (I think I > inadvertently said debian/control in my previous message--oops), if > you implemented (or front-ended for that matter) something like > uscan to grab the current source based on wildcarded version info, > since the upstream URI and upstream version should already be > present. Then a new upstream version, optimally, only results in a > change to debian/changelog and you don't have to go updating a URI > anywhere as a result. Heck, the checksum could even be included in > the "new upstream version" changelog entry in a parseable way so you > wouldn't need to include a separate file to hold that information. Hm, I would rather go for a less instrusive and simplistic approach. Since debian/changelog is parsed by several achive scripts and it could be a little scary to add random stuff in there or to keep its format sane. I would go for debian/copyright and/or debian/rules should be tweaked to cope with digest checking. Also there is no need for an extra file like debian/checksums ;-) 1) Since debian/copyright already contains the upstream URL I would add also the hashes against it in a machine parsable way: It was downloaded from ftp://ftp.coolsite.org/dir/file-1.2.tar.gz md5sum: paranoiccyphers sha1sum: extraparanoiccyphers This information should be updated when you switch to a new upstream release as it should be (new file and new declaration of yours that it has been checked). Further this could be parsed and process from debian/rules by means of get-orig-source own implementation or calling scripts like dpatch-get-origtargz (which sould be patched to cope with digest checks;-) 2) Or just define full URL path to the tarball and hash sums in debian/rules and process them as well. IMO this could be done easily by a prospective sponsee with no risk to break Debian normative documents or any archive tools. -- pub 4096R/0E4BD0AB 2003-03-18 <people.fccf.net/danchev/key pgp.mit.edu> fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
