Re: How to include information about a source package ?
On Mon, May 01, 2006 at 01:01:43AM +0300, George Danchev wrote:
> 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.
Builds are not required to have network access, so rules:build is
required to succeed without it.
Justin
Reply to: