On Tue, May 23, 2000 at 04:13:30PM +0200, Josip Rodin wrote:
> This I second... but the diff itself still has a few issues.
> > @@ -1046,12 +1065,12 @@
> > <p>
> > Every time you put more than one shell command (this
> > includes using a loop) in a makefile command you
> > - <em>must</em> make sure that errors are trapped. For
> > + should make sure that errors are trapped. For
> > simple compound commands, such as changing directory and
> This must remain a `must', not doing so usually results in incomplete or
> unbuildable packages.
If it results in unbuildable packages, that's an RC bug anyway. If it
doesn't, then it's just something that should be fixed, which makes it
just a regular bug.
> > However, because '/usr/local' and its contents are for
> > - exclusive use of the local administrator, a package must
> > + exclusive use of the local administrator, a package should
> > not rely on the presence or absence of files or
> > directories in '/usr/local' for normal operation.</p>
> Why not `must' here?
My rationale was that since they already were required not to put files in
/usr/local, anything further along these lines either wouldn't particularly
matter, or would cause the package to be broken anyway. That, and I tried
to default to `should' where plausible.
But I suspect must makes more sense. Consider it reverted.
> > @@ -1370,7 +1389,7 @@
> > <heading>Writing the scripts</heading>
> >
> > <p>
> > - Packages can and should place scripts in
> > + Packages may place scripts in
> > <tt>/etc/init.d</tt> to start or stop services at boot
> > time or during a change of runlevel. These scripts should
> > be named <tt>/etc/init.d/<var>package</var></tt>, and they
> Leave the `should'.
So a normal bug should be filed against dpkg because it doesn't place a
script in /etc/init.d to start or stop services at boot time or during
a change of runlevel?
> > @@ -2193,7 +2211,7 @@
> > </p>
> >
> > <p>
> > - Please make sure that you use only released versions of
> > + You should make sure that you use only released versions of
> > shared libraries to build your packages; otherwise other
> > users will not be able to run your binaries
> > properly. Producing source packages that depend on
> This must be a `must', because unfulfilled dependency is a Severity: grave
> bug (or at least Severity: important).
Errr. Yes. Changed.
> > <p>
> > + Each program, utiltiy, function and configuration file should
> > + have an associated manpage included in the same package.</p>
> > +
> Leave including of other proposals to the policy maintainers :)
Since policy already says by implication that a bug should be filed if
no manual page is available for a particular program, I figured that
in rewriting the requirements to be more explicit that actually stating
the above made sense.
Although I will admit to sneaking in the "configuration file" bit...
> All in all, I must state for the record :) that reading a unified diff of
> the document wasn't quite a joyful experience. Maybe we should be using
> wdiff (that means `word diff', see the package for details)?
How're you meant to use it? Naively it seems to give a 137k diff for these
changes, which seems long and painful to read through too, although it
does look pretty with less. You can always apply the diff and run wdiff
yourself I guess. :-/
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG encrypted mail preferred.
``We reject: kings, presidents, and voting.
We believe in: rough consensus and working code.''
-- Dave Clark
Attachment:
pgpvC3OGroUKS.pgp
Description: PGP signature