[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Policy for local packages?



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.


Reply to: