Re: First draft of review of policy must usage
On Wed, 25 Oct 2006 20:01:32 +0200, Kurt Roeckx <kurt@roeckx.be> said:
> 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.
Well, we know that packages are in Debian that do not comply
with all directives in policy right now. The wording is poor -- 'all
directives; include SHOULD and MAY as well, and we don not throw
packages out of Debian (or even a stable release) based on even MUST
criteria -- so those bits in policy are just plain wrong.
> @@ -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 is a foto note. Foot notes are not normative.
> 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.
I think there is language elsewhere about that, though.
> @@ -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.
This is advice to the user, and thus not a normative directive
for packaging.
> @@ -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.
Not all packages have to install config files or be buggy --
for example, packages that only ask questions based on information
available only after unpacking, for instance. Such packages may or
may not ask questions, and the question they ask may need values
gathered by programs that are contained in the package itself. In
this case, there can be no config file -- and all the questions are
conditionally asked in the postinst.
Since this is not the default, I use the term "should usually"
provide. not an unconditional should provide.
> <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.
This is something I want to discuss further. Consider the case
where there is a package with a set of, say, 20 binaries with a lot
of common code, and upstream decided to abstract it out into a shared
lib. This is a shred lib used by anyone else, and it is changing
rapidly enough that there is the equivalent of a soname change on
every upload. There is no interest in supporting older versions, or
even having multiple versions of that lib. In this case, either we
can make packaging that software hard (since moving the lib out of
/usr/lib etc may involve some work), or we allow some packages to
include share libs in the package.
I don't know which way one should lean, so I decided to go the
route of fewer bugs.
> @@ -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".
This first part is preamble to the requirements -- and is not
normative, we are just saying it is a good idea to have some
things happen on install.
> Also, if you really want to change that, you might want to change
> the "This requirement" too.
Well, this is a requirement for things to work, just not a
normative requirement for packaging.
> @@ -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.
This is a foot note, so this is not normative.
> 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.
Again, this is an informative footnote.
> @@ -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.
This flows from the Release policy. Not specifying /bin/bash
in scripts is not considered a RC bug.
>> @@ -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.
Same reason. This is not considered an RC bug, so there is no
need for this to be a must. We have it on good authority that this
is not a release critical bug.
manoj
--
Attention to detail is the watchword for gleaning information from an
unsuspecting witness. -- Inspector Cleuseau
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: