Hi, On Tue, Feb 28, 2006 at 07:18:31PM +0200, Panu Kalliokoski wrote: > On Wed, Mar 01, 2006 at 03:52:04AM +1100, skaller wrote: > Thank you for this explanation. Although I still have some issues with > it, it seems I should build infrastructure for building source packages. > (Earlier, one just needed dpkg-source -b; now it seems there must be > some script or makefile target to construct a fake .orig directory and > then build the source with that.) It feels funny that I have to make a > dummy "pristine" source for the Debian project while I've been releasing > the "debian-specific" source outside Debian for ages. I see what you mean. However, both from a technical point of view, and from a philosophical point of view, it makes sense: People who are getting your release tarball will not want to build a Debian package (if they did, they'd get your Debian (source) package directly). Also, people who want to use the package on other distributions should not be bothered with debian-specific stuff. The fact that they bother us with their .spec files doesn't mean we shouldn't be nice to them. ;-) Having the debian/ directory under version control is useful. But it shouldn't be included in the tarball when you run "make dist". Of course, if the debian/ directory is not in the release tarball, you'll need a patch to put it in the Debian source. I'm upstream for most of my packages, and it's normal that the diff.gz only contains the debian/ directory. For non-native packages, there is a technical reason not to include the debian/ directory in the tarball as well: the build system doesn't support removal of files from the source (AFAIK). That means that if there's a file in there that shouldn't be there, it can only be made empty. Since some tools react on the existance of files, this can be a problem. Of course that is just a technical issue which can be solved, but since the debian directory shouldn't be in the upstream tarball anyway, there's no hurry. :-) > > Debian tries to maintain standards of packaging quality. > > This may mean someone else may wish to fix bugs in your > > packaging. If your packaging is part of the source tarball, > > that requires editing the tarball. If the packaging is > > separate, the tarball doesn't change, only the packaging. > > This is true, even for bug fixes to the source itself: > > they're diffs in the packaging, your tarball remains > > invariant. > > Okay, this seems to be the same (probably?) as the "transparent NMU" > thingy. It is indeed. > It is imaginable that we can derive some benefit from > separating the "source distribution" into different bits like packaging > and everything-else -- maybe less stuff to upload, although it won't > make any difference with project sizes like this... The benefits are in size only for large projects, indeed. But there are benefits in readability for all packages (in particular when a new Debian version comes out without a new upstream version, such as usually happens in the case of an NMU). > But I still wonder -- if it is beneficial to separate the packaging from > the other source, would it not be beneficial to separate other > components of the source that are not circularly dependent on each > other? Is it, for instance, a problem that if the _documentation_ of a > piece of software changes, the whole .orig.tar.gz gets updated? Is > there something special about packaging information that makes it > especially vulnerable to separate changes, even when the packager and > the upstream author are the same person? No, it's not especially vulnerable, but because of the strong advise to use pristine sources, it's the only part that can actually be split off. Also, splitting the package in many pieces makes it very hard to get and install all the pieces, and you probably don't want to inflict that on your users. ;-) (Remember that we're talking about the release tarballs here, not about the internals behind the Debian packaging. Some people actually use those release tarballs directly.) Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html
Attachment:
signature.asc
Description: Digital signature