Re: Working on debian developer's reference and "best packaging practices"

[Julian Gilbey <J.D.Gilbey@qmul.ac.uk>]

On Thu, May 02, 2002 at 01:44:50AM -0500, Manoj Srivastava wrote:
>  Anthony> Policy at the moment provides a fairly thorough grounding in
>  Anthony> Debian's best practices. That's highly useful.
> 
> 	Thorough is a matter of opinion. I think it is inconsistent,
>  bumbling mess, occasionally wrong, and bloated, it occasionally
>  contradicts itself, related issues are often scattered throughout the
>  document, it does not have enough rationale. Its coverage of best
>  practices is patchy, and what there is adds to the problem
>  determining what is policy and what is the document merely being
>  chatty.

I totally agree with Manoj here.

I think that before anyone sits down a rewrites the policy document
(which we really need to do!), we should agree on a sensible structure
that is likely to work.  Doing too much detailed writing at this stage
seems a little pointless.

Here is a very brief attempt at a draft structure, which will
certainly need improving, but gives an idea of what I mean:

Part I: The Debian Archive
 1: DFSG and the sections of the archive (free, non-free, contrib, non-us)
 2: The different distributions (stable, etc.)

Part II: Packages and metadata
 3: Package structure (source, binary, arch-dep/indep)
 4: Control fields: source package fields
 5: Control fields: binary package fields
 6: Package dependencies: binary packages
 7: Package dependencies: source packages

Part III: Packaging scripts and files
 8: Maintainer scripts
 9: Other miscellany: debian/rules, changelog, files, substvars, etc.
 10: Configuration files
 11: Shared libraries

Part IV: Other packaging issues
 12: The operating system (cron, init.d, etc.)
 13: Issues concerning files (permissions, links, scripts, etc.)
 14: Documentation

Part V: Debian subsystem issues
 14: X Windows policy
 15: Perl policy
 16: Menu policy
 17: Emacs policy
 ...

Part VI: Programming guidelines and best practices
 [There may be something which fits here]


Then each section could either have the structure:

  Policy dictates
  Discussion, useful information, guidelines, examples

or we could merge them, and have policy dictates all in the form MUST,
SHOULD, MAY, MUST NOT, etc., as in the RFCs.  (As far as RC issues
goes, this could be marked by (RC) after the MUST/SHOULD/whatever,
with a catchall at the start of policy that the final decision on what
is RC rests with the release manager.)

   Julian

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

      Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London
              website: http://www.maths.qmul.ac.uk/~jdg/
   Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/
     Visit http://www.thehungersite.com/ to help feed the hungry


-- 
To UNSUBSCRIBE, email to debian-project-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org