On Sun, Jul 28, 2002 at 07:29:57AM -0600, Julian Gilbey wrote:
> To split the (often borderline) cases of specs versus guidelines seems
> to me to be somewhat misguided.
Well, that's nice, but if our best reason is "it seems to me", we're not
going to get anywhere, because it seems to me to be quite the opposite. We
could arm wrestle for it, I guess?
For a more useful take, here, roughly, is what I'd think the tables of
contents for the two documents might look like:
__Best Packaging Practices__
Making a package
Locating your package (server, component, priority, tasks, sections)
Versioning your package
Architecture considerations
When to use Depends/Pre-Depends/Recommends/Suggests/Provides
Effects of Essential: yes?
What to put in your Description
Making a source package
should you do things...
by hand?
with debhelper?
with debstd?
with dbs?
with cvs-buildpackage?
how you should write your changelog
copyright file
what gcc options to use, environment variables to use
supporting DEB_BUILD_OPTIONS
Other general stuff
file locations
/usr/share/doc
symlinks
users and groups
file permissions
dpkg-statoverride, and when packages should use it
preinst, postinst, prerm, postrm
what tools are available
when to prompt
configuration
conffiles versus postinst
when and how to change from to the other
what happens when your conffile _has_ to change
sharing configuration files amongst multiple packages
that aren't installed together
that are installed together
automatically handling files in /etc
automatically updating config files
"/etc/auto" and symlinks, etc
init scripts (which runlevels, messages, how to write them)
cron jobs
menus
environment variables
don't expect them
$EDITOR || /bin/editor
$PAGER || /bin/pager
alternatives versus Provides/Conflicts
MIME stuff
/dev/*
user configuration files
log files
ptys, wtmp, utmp, lastlog
i18n/l10n
references for gettext, man pages, debconf
keyboard handling
misc security info
/tmp/races and how to avoid them
renaming, merging and spliting packages
don't do it!
dummy packages
replaces
conflicts/provides
Special cases for when you're packaging...
...scripts
put a #! in them
/bin/sh for POSIX scripts
/bin/bash for bash scripts, but use /bin/sh if possible
t/csh scripts need deps on c-shell
perl scripts can only use stuff in perl-base
python scripts need deps on python
.../bin/sh interpretors
diversions only (and how to manage it)
what you have to comply with
...internet servers
when to use inetd / standalone, how to offer the choice
how to use inetd
how to get /etc/services updated
using TCP-wrappers
...documentation
...C libraries
...emacs stuff
...fonts
...games
...MTAs, MDAs and MUAs
...perl stuff
...python stuff
...webservers
...web services
...X servers
...X clients
...X terminal emulators
...X window managers
There's probably a better way of structuring it.
__Debian Standards Document__
dpkg:
version format
package format
.deb is an ar of tars, etc
maintainer scripts are run when and under what circumstances
what control file fields mean
source format
.dsc fields
.tar.gz, .diff.gz, .orig.tar.gz structure
debian/rules interface
contents/format of debian/control, debian/changelog etc
dselect interfaces
/var/lib/dpkg/status, available, dselect methods, etc
internal dpkg interfaces
/var/lib/dpkg/info, alternatives, statoverride
debconf:
.templates format
.config arguments, etc
interface for frontends
update-menus / menu file format
There're probably other interfaces that're complicated enough to deserve
formal documentation. SELinux might be one, eventually. I'm not really
sure, perhaps Manoj'll comment.
Basically, to my mind, BPP should be focussing on the what and the why,
and basically always refer the details of /how/ to other documents,
either some program/package's manpages or the "Debian Specs Document".
The "Or Else" should be kept minimal, and left entirely to other groups
(the RM, the tech ctte, the archive scripts, eg), IMO. This is the
"policy shouldn't be a stick" philosophy.
So why should you care about either document? Abusing dpkg's internals
will mean your programs don't work, so you should obviously care about
the specs doc. And, really, who here *doesn't* want their packages to
be the best they possibly can be?
Forgetting whether all the above's good or bad momentarily, is it at
least clear what I'm saying, and that for any given desirable bit of
policy, there's some way of including it?
Cheers,
aj
(Comparing the BPP/DSD dichotomy with the policy/packaging-manual split
is left as an exercise to the reader...)
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``If you don't do it now, you'll be one year older when you do.''
Attachment:
pgpVfwFoOqElw.pgp
Description: PGP signature