Hi all, About a week ago, I gave a course at a customer about packaging Debian packages. While preparing and giving the course, I was reminded of something I'd been meaning to bring up before:
Debian's policy document, and many of Debian's tools, assume that any built Debian package is always intended for upload into Debian proper, or at least for wide distribution. This isn't always true; and for people who wish to make internal-use-only packages, this makes it much harder to figure out which part of the documentation is relevant for them and which part isn't. Let me explain what I'm on about here. There are several things in policy which are technical requirements or expectations that other parts of the Debian infrastructure expect packages to abide by. For instance, the bits in policy which specify that library packages should provide either a shlibdeps or a symbols file are technical in nature; providing library packages which don't do such a thing will make it harder to build proper packages which use these libraries, since dpkg-shlibdeps won't find them. Similarly, the fact that we have a short dependency and a long dependency, and that these are not related and should be considered as two distinct things, is a technical requirement. At the same time, some of the requirements in policy are things that we really really want for packages uploaded to Debian, and that people should probably abide by if they produce a package for wide distribution, but aren't very critical for packages that are intended for internal use only. For instance, if you have a local policy that says your webapps should be installed to a particular directory under /opt, then it makes perfect sense (and will probably not break anything) if your packages install your webapps into /opt rather than somewhere under /usr/share. Similarly, if you have a local QA team which vets a particular compiled version of a binary, and your local policy forbids ever recompiling any QA-vetted binaries for mere packaging (instead, your scripts must build RPM, Windows, MacOS, and Debian packages from the same compiled java binary), then it's probably perfectly fine to have a debian/rules which doesn't compile anything, but instead just copies the already-compiled binaries into place. Obviously you wouldn't want to distribute those packages anywhere, but that doesn't mean it's a bad idea to make them if that makes your life easier. Occasionally, these latter two were actual requirements at the customer where I was giving that course last week. Also, the fact that policy mixes these two kinds of requirements into one document has caused some people to ignore it[1], with all consequences thereof. I think it would make sense to document which parts of policy fall in the "technical requirements and/or expectations" category, and which parts don't. This would allow people to understand how to build a simple local package, without having to filter out the information that (to them) is irrelevant anyway. Thoughts? [1] see, for instance, <https://github.com/jordansissel/fpm>, and especially the speaker notes on slide 18 in the presentation that's linked from there. -- Copyshops should do vouchers. So that next time some bureaucracy requires you to mail a form in triplicate, you can mail it just once, add a voucher, and save on postage. -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130121205206.gb29...@grep.be
