Bug#704233: Policy for local packages.
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-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: http://lists.debian.org/20130121205206.GB29049@grep.be
Reply to: