[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#250202: mandate a common name for "patched source" and/or "unpacked source"o

On Fri, May 21, 2004 at 11:27:27AM +0200, Wouter Verhelst wrote:
> Package: debian-policy
> Severity: wishlist
> OK, I'm sick of this.
> There are a number of dbs-style packages out there, that don't give you
> the source if you say "dpkg-source -x .dsc"; instead, they give you a
> directory with a source tarball and a bunch of patches. While this is
> probably a good idea to make maintaining said packages easier, the fact
> that they all have different debian/rules targets for unpacking sucks
> majorly; if you want to apply a small local patch, you have three
> options to find out what the right targets are:
> * Guess (which is hardly successful, IME)
> * Call one of the more common debian/rules targets, such as "configure"
>   or "build", and interrupt it when it starts doing stuff you don't
>   actually need.
> * Read makefile sources. Usually, this involves tracking where a given
>   variable is given a value, by searching a number of included
>   makefiles. While not impossible or hard, it's very annoying that this
>   has to be done in the first place, and a waste of time IMHO.
> Wouldn't it be a good idea to add two targets to the debian/rules file,
> say, "unpacked" and "patched" or something[1], which would unpack the
> source, resp. patch it using the provided patches? These targets would
> be mandatory if an unpacked source package would not provide an unpacked
> source tree, and optional otherwise.

I would prefer if they do not require to run such target in the first
place. There is no need for it, you can just ship the patches preapplied
(with dpatch, it is just a matter of making clean depend of patch
instead of unpatch). I heard that doogie is developing a new release of
dbs that would not require to run such target anymore.

Also all my packages with non-trivial source process include a file
./README.source that explain how source should be handled. So that 
could be an alternative solution that does not convey that it is
suitable to require the user to run such target.

Bill. <ballombe@debian.org>

Imagine a large red swirl here. 

Reply to: