Re: MUST and SHOULD in policy
On Fri, Apr 28, 2000 at 07:10:45PM +1000, Anthony Towns wrote:
> <item>
> <p>
> - must not be so buggy that we refuse to support them,
> + should not be so buggy that we refuse to support them,
> </p>
> </item>
> <item>
> <p>
> - must meet all policy requirements presented in this
> + should meet all policy requirements presented in this
> manual.
> </p>
> </item>
If you change the former line, that would mean that we may (hypothetically,
of course) refuse to support foo which is in main, but it would still be
suitable for release, i.e. it would be a normal bug? I don't quite like it.
You could change the latter line to match current status, but that simply...
doesn't look good :) We should have full policy compliance as one of the
goals, important ones... but it's not doable right now.
> @@ -510,7 +519,7 @@
> <heading>Priorities</heading>
>
> <p>
> - Each package is given a certain <em>priority</em> value,
> + Each package <em>must</em> have a <em>priority</em> value,
> which is included in the package's <em>control
> record</em>. This information is used in the Debian package
> management tool to separate high-priority packages from
So, we would need to go over each of these 804 packages (as reported by
Lintian) that don't have it? Or is having a proper entry in the override
file (that includes the priority) enough?
> @@ -586,7 +597,7 @@
> </taglist></p>
>
> <p>
> - Packages may not depend on packages with lower priority
> + Packages <em>must not</em> depend on packages with lower priority
> values (excluding build-time dependencies). If this does
> happen, one of the priority values will have to be adapted.
> </p>
Richard said that this isn't RC.
> <p>
> - For example, for any shared libraries required by
> - dynamically-linked executable binary in a package a
> - dependency entry has to be provided.</p>
> + For example, a dependency entry has to be provided for any
> + shared libraries required by dynamically-linked executable
> + binary in a package .</p>
~ remove the space </nitpick> :)
> + It build-time dependencies are specified a package <em>must</em>
ITYM I_f_...
> @@ -973,25 +984,25 @@
>
> <p>
> If changes to the source code are made that are generally
> - applicable please try to get them included in the upstream
> - version of the package by supplying the upstream authors
> - with the changes in whatever form they prefer.</p>
> + applicable they should be sent to the upstream authors in
> + whatever form they prefer so as to be included in the
> + upstream version of the package.</p>
Great to see that this would become a reason for filing a normal bug.
> <p>
> - Please make sure that the <prgn>configure</prgn> utility
> - detects the correct architecture specification string
> - (refer to <ref id="arch-spec"> for details).</p>
> + You should make sure that the <prgn>configure</prgn>
> + utility detects the correct architecture specification
> + string (refer to <ref id="arch-spec"> for details).</p>
IIRC several porters have been filing these as RC bugs so far, if it made
the package unbuildable... since the fix isn't complcated, maybe this should
be a `must' case.
> @@ -1008,8 +1019,9 @@
> <heading>Documenting your changes</heading>
>
> <p>
> - Document your changes and updates to the source package
> - properly in the <tt>debian/changelog</tt> file.</p>
> + You should document your changes and updates to the source
> + package properly in the <tt>debian/changelog</tt>
> + file.</p>
However this would indicate that filing normal bugs on faulty changelog
entries is preferred. Maybe it should be clarified that changelogs shouldn't
be retroactively edited (that's called modifying history :), but that the
new changelog entries should contain corrections for the old ones.
> @@ -1397,7 +1409,7 @@
> </taglist>
>
> The <tt>start</tt>, <tt>stop</tt>, <tt>restart</tt>, and
> - <tt>force-reload</tt> options must be supported by all
> + <tt>force-reload</tt> options <em>must</em> be supported by all
> scripts in <tt>/etc/init.d</tt>, the <tt>reload</tt>
> option is optional.</p>
>
<unrelated to the patch itself> This is a tricky one. Does ignoring $1 count
as supporting? What about scripts that are only meant to be linked from
/etc/rcS.d/? OTOH maybe I should re-read the sysvinit policy... :)
> + If a program usually depend on environment variables for its
ITYM depends.
> + configuration, the program should to be changed to fall back
> + to a reasonable default configuration if these environment
> + variables are not present. If this cannot be done (e.g., if
> + the source code of a non-free program is not available), the
> + program <em>must</em> be replaced by a small `wrapper' shell script
> + which sets the environment variables if they are not already
> + defined, and calls the original program.</p>
...or the code should be added to the program itself to do it.
> - files must go in the run-time library package. This is a
> + files <em>must</em> go in the run-time library package. This is a
> good idea in general, and especially for static linking
> - issues.
> + issues. (Huh?)
:)
> - These two styles of configuration file handling <em>must
> - not be mixed</em>, for that way lies madness:
> + These two styles of configuration file handling <em>must</em>
> + not be mixed, for that way lies madness:
Emphasize "not", too.
> respectively. These are two scripts provided in the Debian
> base system that check the EDITOR and PAGER variables and
> - launches the appropriate program or falls back to
> + launche the appropriate program or fall back to
ITYM launch.
> should only use sections 1 to 9 (see the FHS for more
<also unrelated with the patch itself>
This is wrong, section 9 is obsoleted both by FHS and by man(7).
--
Digital Electronic Being Intended for Assassination and Nullification
Reply to: