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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
