Re: question on packaging when not software maintainer
On Tue, Feb 08, 2011 at 03:24:27PM +0100, Olivier Sallou wrote:
> I am packaging a software (GBrowse) but I am not the developper of the
> software. To create a correct package, I need to update the install
> scripts.
That's usually done via patches. The workflow is: Unpack the upstream
source, copy the debian/ directory into the root folder of the unpacked
source, cd into this folder and say:
$ quilt push -a # to apply all old patches (if there are any)
# if patches do not cleanly apply fix those patches
$ quilt new <name_of_the_patch>.patch
$ quilt edit <file(s)_that_need_to_be_patched>
$ quilt refresh
# it is very good style to add a header with Author, Date, and
# description to debian/patches/<name_of_the_patch>.patch
> I wonder how this should be manage:
>
> - Should I keep the watch file on remote server to track new releases,
The watchfile just contains a *link* to the remote server. The file
itself belongs to the package and you can in addition keep it on your
own box to run a periodical cron job which keeps yourself up to date.
(BTW, I'm busy writing code which sends a weekly mail about new upstream
versions to the developer list but that's a bit delayed because of
technical problems I faced with UDD.)
> put in Debian SVN the specific install scripts, and specify in
> README.Debian that specific scripts should be copied in untar'd orig
> source file before builing package ?
Anything which addresses issues a developer has to be concerned about
belong to README.source. The file README.Debian just contains user
oriented information.
> - Should I create a get-orig-source that gets the remote code, replace
> whatever is needed and create an orig-source-file ?
If at all possible you should keep the orig-source-file untouched.
Valid reasons to touch the original tarball are for instance: Removing
unneeded binary chunks, remove possibly unwanted non-free code,
repackaging zip -> tar.gz. In case upstream also moves VCS cruft
(CVS, .svn directories) I personally repackage it and delete it (in
case upstream does not change it after explicite request.
Changing the upstream tarball just to change the code of some install
routines is no valid reason for repackaging. This should be done in
patches (as mentioned above). There might be cases where it makes sense
to educate upstream to include some command line options into their
installation procedure which makes your live more easy.
> - Or should I put the whole source file in SVN, and take in charge the
> updates of the code ? (not fond of this solution)
No. That's not needed.
Hope this helps
Andreas.
--
http://fam-tille.de
Reply to: