On Wed, 25 Oct 2006 20:01:32 +0200, Kurt Roeckx <[EMAIL PROTECTED]> 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.
>
>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 @@
>
>
> The build, binary and
> - clean targets must be invoked with the current
> + clean targets need to be invoked with the current
> directory being the package's top-level directory.
>
>
> 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 @@
>
>Additionally, packages interacting with users using
>debconf in the postinst script should
> - install a config script in the control area,
> - see for details.
> + usually install a config script in the control
> + area, see for details.
>
>
>
> 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.
>
> - 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 instead.
> + the shared library packages are in
> + instead.
>
>
>
> 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 @@
>
>
> If a package contain
