Re: How to include information about a source package ?
On Monday 01 May 2006 00:11, Jeremy Stanley wrote:
> On Sun, Apr 30, 2006 at 10:06:59PM +0300, George Danchev wrote:
> > Nobody says that get-orig-source must be only used for repackaging
> > purposes. I think it is fine to have such target just getting the
> > upstream source (ok a hash checking against a previously checked
> > and trusted version is required) without further modifications
> > over it which is to be built on the autobuilder or end user side.
> > Any worries with that ?
>
> This sounds, to me, to be bordering on redundancy with the purpose
> of including a debian/watch file, as both would likely be pointing
> to similar sources (one for new versions, one for the current
> version with a MD5 hash as a sanity check).
Now I remember the dpatch-get-origtargz(1) from dpatch package which should be
enhanced to do sanity checks against a trusted hash sum(s). Now I remember
bug #325161, there is also a patch which should be polished somehow ;-)
> To take it even further,
> I'd be interested in a marriage between the upstream source location
> in debian/copyright and a target in debian/rules that would allow
> you to:
>
> a) eliminate the need to put the upstream URI in multiple files
> b) subsume or at least auto-generate a debian/watch, as desired
>
> Maybe have a machine-parsable URI in debian/copyright (since policy
> requires the upstream source origin to be indicated therein anyway),
> and then make a debian/rules target that creates a debian/checksum
> containing a MD5/SHA1 digest of the original upstream source and a
> usable debian/watch (for backward compatability with uscan, since
> you could at this point easily replace its functionality with
> another make target anyway). Then the get-orig-source target could
> determine the upstream version from debian/control, retrieve the
> proper source tarball from upstream via the URI in debian/copyright
> and verify it against the debian/checksum contents, followed by (in
> cases where needed) performing removal/adjustment and repacking of
> the contents to create the maintainer's mangled substitute.
>
> I know this smacks of being a solution in search of a problem, but
> would the above automation scenario be considered a voilation of
> packaging policy/guidelines, obfuscated or unnecessarily cumbersome?
> I'm tempted to play around with the ideas above and throw together a
> mockup (just for fun).
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.
--
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: