Package: debian-policy Severity: wishlist Le Mon, Jan 21, 2013 at 09:52:06PM +0100, Wouter Verhelst a écrit : > > 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.
Hi Wouter, sorry for the lack of answer. As explained by Russ on debian-vote@l.d.o, we have a big backlog and a not much manpower. But in any case, please do not hesitate filing bug reports for your suggestions. Observing the work done in the past year, I would say that it roughly consists in a few large modifications seasonned with low-hanging fruits. The next large modifications we plan are the documentation of triggers and multiarch, and then a major restructuration which will be the opportunity to switch to DocBook XML. People more interested in the idea you propose are of course welcome to focus on it. A lot of preparatory work is needed anyway. I am creating an entry in the BTS to keep track. For convenience, I keep the rest of your original email cited below. Have a nice week-end, -- Charles > > 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 -- 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/20130330004359.ga23...@falafel.plessy.net
