On Fri, 2008-05-30 at 15:07 -0500, Paul Johnson wrote: > Keep in mind that my background is in RPM building, where the emphasis > is on distributing "pristine" source code. I was initially > shocked/dismayed by the Debian approach because the source code gets > untarred and fiddled with by the packager. Wherever possible, changes should be limited to the debian/ directory. > Some of the example guides > that people referred me to may have been bad examples--packagers were > opening the source directory and liberally applying patches and making > changes, and all of those fiddles were getting wrapped up into the one > big diff file, making it impossible to figure out who did what. Who did what is in debian/changelog and some patches have attributions and comments. > I eventually found out that these were bad examples. At the end of > the day, the recommendation for Debian packaging is essentially the > same as in RedHat: we are aiming to distribute unchanged source that > is patched in a clear and orderly way. There's not much information on > how to manage patches in the Debian New Maintainer's Guide, but in > section 6.4 it does acknowledge the problem and refers to dpatch. dpatch is only one way - CDBS is another, quilt a third and there are moves afoot for a new source format, based on the quilt model. > I keep wondering, "If the goal is to re-distribute 'pristine' source > code and patches, why doesn't Debian discourage users from untarring > the sourced code?" users? You mean developers and maintainers? > Why can't you make it so the debian directory is > not inside the source tree? Actually, there are few good reasons to do that and it causes more trouble than it would be worth IMHO. > One response I've received is that "we > are not RedHat, try to get over it." True. > I wonder how you do your day-to-day work on building debs? I have > followed the dh_make approach of opening the source, and dh_make gives > me template files in "debian" for control, rules and such. Only use dh_make once per package - there should be no need to ever run dh_make again. > After configuring those, I try to do a package build. While testing > this out, I realize I've made some mistakes while attempting to revise > the Makefile to match the packaging requirements. Wherever possible, pass those changes via variables in debian/rules, not by altering the Makefile. Remember that debian/rules *is* a Makefile. > It appears to me > that I have to 1) move the debian directory to a safe place, 2) erase > the code tree, 3) untar a fresh copy, 4) copy the debian directory > back into the source tree, and 5) start over trying to fix the > Makefile. Is that how you do it? NO! :-) Use the clean target to get back to the distributed source and dh_clean to get a clean debian directory with just the essential files. > One suggestion I receive is to do > this work in a directory managed by rcs or subversion. I think that > would be fine too, but harder to set up when you just want to quickly > build some small package that somebody distributed for, say, RedHat or > such. And the Debian diff for the package would then pick up all the > rcs files, right? No. Use the relevant tool and these will be skipped - cvs-buildpackage, svn-buildpackage etc. > In a test case I was working on, the build failed because of a > mismatch between the libtool & automake that were used to create the > source_orig.tar.gz file and the versions available on the current > system. As a result, it was necessary to run "autogen.sh" in the > source directory before trying configure. That process creates a > bunch of files that should NOT be included in the Debian diff file, > such as changes in config.sub or such, but the Debian package does > include those things. Then clean them in the clean target (I've got problems like this in one of my own packages, it can be a bit tricky at times but generated files like those *must* be removed in the clean target.) > In building RPMS, the source code patches are applied, but the output > from autogen and configure is not wrapped up into the changes that are > packaged. Use CDBS and it will do the same for you. > It occurred to me that I could try to work around this by using a > build directory that is completely outside of the source code tree. No. The solution is to use the autotools support to clean the source and dh_clean to clean the debian temporary files. > In many packages that use autotools, we've found it convenient to > build outside of the source tree and add the --srcdir option to the > configure command. This leaves the source completely unchanged. I've > not succeeded in doing this while building a Debian package, however, > because it seems to always want to build stuff in the source tree > itself. In the process of changing that, I've become confused about > the sorting of installed files into packages. I'm building library > packages and haven't yet mastered the problem of installing the files > into debian/tmp and then using package.listing files to specify the > files that need to be selected for each Debian package. Library packages are very difficult to package properly. Choose a simpler package to learn first. Libraries need SONAME handling, versioned symbol handling, -dev and -dbg package splits, often -doc packages too. I would *never* advise anyone to start Debian packaging with a library. Package at least two applications or utilities before even considering working on a library. (By "package" I mean to the point where a sponsor is willing to upload the package because all the packaging problems have been fixed.) Learning Debian packaging is a process - it can be a long process and it will only get longer and more confusing if you start with a library. -- Neil Williams <codehelp@debian.org>
Attachment:
signature.asc
Description: This is a digitally signed message part