Re: inclusion of a debian dir in upstream src
Daniel Kobras <kobras@tat.physik.uni-tuebingen.de> writes:
> On Wed, Sep 25, 2002 at 04:57:45AM +0200, Erich Schubert wrote:
> > > > Is it a good idea to keep a debian directory upstream? I have CVS access,
> > > > so I think it'd make it easier for me, and also for others who want to
> > > > build custom debs, if the debian files were in CVS.
> >
> > My personal experience is that "debian" dirs in the main CVS tree SUCK.
> > For example galeon has a "debian" dir in CVS; when i update the checkout
> > i have to backup my debian dir, cvs update, remove the checked out
> > debian dir, then restore my own debian dir.
> >
> > You can always put the debian dir into a different cvs repository.
> > If you keep it separate it's easier for users that want to package the
> > application differently.
>
> The sanest suggestion I've seen so far is to keep upstream's Debian
> scripts in a directory 'deb', and symlink it to 'debian' in configure,
> provided there's no real 'debian' directory. This way, the Debian
> maintainers can easily override it in their diffs without clashes.
>
What I do for the packages where I'm upstream, too, is to have the
main CVS branch not have any distribution-specific things at all. If I
decide to package a specific version (say it's tagged release-0_foo),
I do the following:
1. Create a CVS branch for the debian packaging and fixing (the
commands are from memory, you'd better assure they make sense by
looking up in CVS info):
cvs rtag -r release-0_foo -b debian-0_foo
2. Merge in the debian branch from the last packaged version (say it's
tagged debian-0_bar) (or invoke dh_make alternatively):
cvs update -d -j debian-0.bar # or dh_make, if you have no previous branch
3. Fix any conflicts and do the work to properly package the new release.
4. Once the thing builds and I like it, I commit all changes, upload
the resulting packages and tag CVS with a release tag
(e.g. debian-0_foo-1).
5. I can then continue to work on my branch, merge in changes from
HEAD (if HEAD fixes bugs, for instance) and release subsequent
revisions (that is, repeating point 4 over and over), until there
is a new release I want to branch off.
IMO, this is a nice way to handle debian packages if you have write
access to upstream CVS, without affecting upstream development at all
(just agree about debian branch names & release tag names).
Regards, Andy
--
Andreas Rottmann | Dru@ICQ | 118634484@ICQ | a.rottmann@gmx.at
http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc
Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62
Reply to: