Re: debian directory included in upstream
On Thu, Apr 14, 2005 at 12:09:45PM +0200, Geert Stappers wrote:
> On Wed, Apr 13, 2005 at 02:33:49PM +0200, martin f krafft wrote:
> > also sprach Margarita Manterola <margamanterola@gmail.com> [2005.04.13.1359 +0200]:
> > > ??? Users of __stable__ won't ever get that piece of software, no
> > > matter if it goes into unstable, testing, or any other distribution
> > > you might make up.
> >
> > Users of stable can just as well add unstable deb-src links to
> > sources.list. That's probably even better than pulling the software
> > from xyz and compiling it in /tmp. Use `apt-get -b source`!
> >
> > > Please, do acknowledge that having a debian directory in upstream
> > > does make sense for a lot of different motives.
>
> I acknowledge that having a debian directory in upstream does make
> sense. One motive is giving users easy to a -dbg package.
>
>
> apt-get source conglomerate
> cd conglomerate-x.y.z
> fakeroot dpkg-buildpackage -uc -us
> # was not necessery, only for a clean build check
> debian/rules conglomerate-dbg
> su -c "dpkg -i ../conglomerate-dbg_x.y.z-n_arch.deb"
This is irrelevant to whether to have debian/ in upstream .orig.tar.gz.
The same would have been possible without that, and then the debian diff
would be actually listing the changes of the upstream code and the
packaging code w.r.t. the upstream source.
For example, I note you have dpatches in the upstream tarball, patching
'omf.make'. There is a difference between the upstream sources and the
debian version because of this dpatch, but the actual patch is hidden in
the upstrema tarball, and not in the debian .diff.gz where it is
intended to be.
And, as has been said before, via .diff.gz you cannot remove a file,
suppose that you'd need to remove a file from debian/ in a Debian
revision (for example, the prerm since it's not needed anymore), you
cannot do that, you can only replace it with an empty one now.
> <screenshot>
> stappers@bahrain:/usr/src
> $ zcat conglomerate_0.9.0-1.diff.gz
> --- conglomerate-0.9.0.orig/debian/changelog
> +++ conglomerate-0.9.0/debian/changelog
> @@ -1,8 +1,8 @@
> -conglomerate (0.7.16-2) UNRELEASED; urgency=low
> +conglomerate (0.9.0-1) unstable; urgency=low
>
> - * expecting new upstream version
> + * new upstream version
>
> - -- Geert Stappers <stappers@debian.org> Sat, 1 Jan 2005 15:58:34
> +0100
> + -- Geert Stappers <stappers@debian.org> Wed, 16 Feb 2005 22:36:18
> +0100
Confusing IMHO...
> > > Maybe it does not
> > > make sense to distribute it with a release, but putting it in
> > > a branch, as you said, is too much extra work for upstream.
> >
> > sounds like the wrong version control system to me. :)
>
> <sarcasme>
> Yeah, the version control system as an argument
> to ban the debian directory from upstream.
> </sarcasme>
You can easily make the 'make release' makefile rule exclude the debian
dir from releasing a tarball, and placing the .orig.tar.gz right, you
can then generate the diff straight from an exported or even simply
checkoutted copy of the upstream version control system.
> > > If he wants to have a debian directory, it's his right as upstream
> > > to have it. Although it is a good idea to discourage distributing
> > > it.
> >
> > Sure it's his right. I still do not see a reason why it would be
> > needed upstream.
>
> Indeed, a debian directory is _not needed_ upstream.
> Some how I feel you are fighting against a debian directory in upstream.
> If you weren't visible at good places, I would have to asked
> to let upstream decide what goes in the released tarball
> and to do something else as saying "others should not ...."
Besides the fact a lot of the cases where upstream tarball has a debian/
dir, it's because of overlap maintainer & upstream:
it's indeed something upstream needs to decide, but Debian and the
Debian maintainer could (and IMHO should) argue to upstream to not
include debian/ in the original tarball.
--Jeroen
--
Jeroen van Wolffelaar
Jeroen@wolffelaar.nl (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl
Reply to: