Re: First draft of review of policy must usage
On Wed, Oct 25, 2006 at 01:03:11AM -0500, Manoj Srivastava wrote:
> Next, I removed clauses that said that all the requirements of
> policy must be met for a package to be in main or contrib; we know
> that is not true.
>
> I have replaced some uses of the word must when it was
> intended to be non-normative with alternate and equivalent wording,
> which makes it easier to grep for "must". This still needs to be
> done for should (which I often replace with 'ought to').
So, you changes some things from must to needs, because we don't
consider them RC anymore. But then also remove the requirement
to comply with the policy for us to distribute it?
I think you're trying to do the same thing twice. I don't think we
should remove the requirement to comply with all the requirements.
> @@ -986,7 +891,7 @@
> particular version of that package.<footnote>
> <p>
> Essential is defined as the minimal set of functionality
> - that must be available and usable on the system even
> + that have to be available and usable on the system even
> when packages are in an unconfigured (but unpacked)
> state. This is needed to avoid unresolvable dependency
> loops on upgrade. If packages add unnecessary
Why do you downgrade this? Maybe this should be reworded though.
This seems to be the only place in the policy that says that an
essential package must have all it's functionality when it's in an
unpackaged state. I think that should atleast be moved to the part
about essential (3.8) instead of a footnote about Dependencies.
> @@ -1931,7 +1848,7 @@
>
> <p>
> The <tt>build</tt>, <tt>binary</tt> and
> - <tt>clean</tt> targets must be invoked with the current
> + <tt>clean</tt> targets need to be invoked with the current
> directory being the package's top-level directory.
> </p>
>
I don't see why you want to change that. I think packages rely on it
that it's called with a proper current working directory.
> @@ -3195,8 +3112,8 @@
> <p>
> Additionally, packages interacting with users using
> <tt>debconf</tt> in the <prgn>postinst</prgn> script should
> - install a <prgn>config</prgn> script in the control area,
> - see <ref id="maintscriptprompt"> for details.
> + usually install a <prgn>config</prgn> script in the control
> + area, see <ref id="maintscriptprompt"> for details.
> </p>
>
> <p>
You seem to have changed "should" to "should usually", and I don't
see what the real difference is.
> <p>
> - Packages involving shared libraries should be split up into
> + Packages involving shared libraries ought to be split up into
> several binary packages. This section mostly deals with how
> this separation is to be accomplished; rules for files within
> - the shared library packages are in <ref id="libraries"> instead.
> + the shared library packages are in <ref id="libraries">
> + instead.
> </p>
>
> <sect id="sharedlibs-runtime">
I think the "should" there was good.
> @@ -4722,7 +4640,7 @@
>
> <p>
> If a package contains a binary or library which links to a
> - shared library, we must ensure that when the package is
> + shared library, we have to ensure that when the package is
> installed on the system, all of the libraries needed are
> also installed. This requirement led to the creation of the
> <tt>shlibs</tt> system, which is very simple in its design:
I have no idea why you want to change that. If it's linked to a shared
library, it really needs that library and won't work without it. So
this should be a "must".
Also, if you really want to change that, you might want to change the
"This requirement" too.
> @@ -4748,7 +4666,7 @@
> determined by calling <prgn>ldd</prgn>, but now
> <prgn>objdump</prgn> is used to do this. The only
> change this makes to package building is that
> - <prgn>dpkg-shlibdeps</prgn> must also be run on shared
> + <prgn>dpkg-shlibdeps</prgn> also has to be run on shared
> libraries, whereas in the past this was unnecessary.
> The rest of this footnote explains the advantage that
> this method gives.
It really must be run on it, or things will break.
> @@ -4865,7 +4783,7 @@
> determine whether <tt>foo-prog</tt>'s library
> dependencies are satisfied by any of the libraries
> provided by <tt>libfoo2</tt>. For this reason,
> - <prgn>dpkg-shlibdeps</prgn> must only be run once
> + <prgn>dpkg-shlibdeps</prgn> has to be run only once
> all of the individual binary packages'
> <tt>shlibs</tt> files have been installed into the
> build directory.
If you remove that requirement, I think you need to another one.
foo-runtime really needs to have a dependency on libfoo2, one way or
another.
> @@ -6736,10 +6654,10 @@
> the LSB anyway.
> </footnote>
> Thus, shell scripts specifying <file>/bin/sh</file> as
> - interpreter must only use POSIX features. If a script
> + interpreter should only use POSIX features. If a script
> requires non-POSIX features from the shell interpreter, the
> - appropriate shell must be specified in the first line of the
> - script (e.g., <tt>#!/bin/bash</tt>) and the package must
> + appropriate shell should be specified in the first line of the
> + script (e.g., <tt>#!/bin/bash</tt>) and the package should
> depend on the package providing the shell (unless the shell
> package is marked "Essential", as in the case of
> <prgn>bash</prgn>).
Why do change the second and third must to a should?
If the script uses features from bash, and /bin/sh points to for
instance dash, it's going to break. So you either stick to POSIX, or
you say which shell you need.
Also, when the script needs dash, and has #!/bin/dash, and dash is not
installed, it's not going to work, so we really need that depedency.
> @@ -6766,7 +6684,7 @@
> Harmful</em>, one of the <tt>comp.unix.*</tt> FAQs, which
> can be found at <url id="http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/";>.
> If an upstream package comes with <prgn>csh</prgn> scripts
> - then you must make sure that they start with
> + then you have to make sure that they start with
> <tt>#!/bin/csh</tt> and make your package depend on the
> <prgn>c-shell</prgn> virtual package.
> </p>
Same as previous.
Kurt
Reply to: