Re: How to include information about a source package ?
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
Reply to: