|
Home > Archive > Debian Developers > October 2006 > First draft of review of policy must usage
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
First draft of review of policy must usage
|
|
| Manoj Srivastava 2006-10-25, 1:35 am |
| | |
| Luk Claes 2006-10-25, 1:35 am |
| Manoj Srivastava wrote:
> Hi,
Hi Manoj
Can everyone please focus on the release and discuss things that don't help to
release on December 4th at all till after that date?
Thank you very much.
Luk
PS: For those people that seem to think they can't help: there is still along
list of RC bugs, the release notes definitely still need work, translations
can still be improved, installation and upgrade tests are always welcome...
--
Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D
Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D
| |
| Manoj Srivastava 2006-10-25, 7:19 am |
| Dear Luk,
On Wed, 25 Oct 2006 08:16:59 +0200, Luk Claes <luk@debian.org> said:
> Manoj Srivastava wrote:
[vbcol=seagreen]
> Hi Manoj
> Can everyone please focus on the release and discuss things that
> don't help to release on December 4th at all till after that date?
> Thank you very much.
The next time you feel the urge to be patronizing, ponder on
these:
a) what gives you the right to pontificate and tell people what to
do from your high horse?
b) Why do you think getting on a soap box is likely to help
anything, including a dialogue on this list?
c) that for some of us doing things right trumps releasing on some
arbitrary deadline hands down?
Part of doing things right it to lick the technical policy in
shape; reviewing the must directives for bloat has been long
overdue. If the policy is so far from reality that release managers
do not consider violation of must directives as something that would
compromise the high standards of what Debian considers fit for
release, then it seems to me we need to fix policy.
Now, if you can stop lecturing and review the changes, and
provide feedback on whether my judgement for thechanges is on the
right path, you would be helping. If noit, could you please let the
rest of us work on getting a better technical policy out?
thank you,
manoj
--
Give him an evasive answer.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Andreas Barth 2006-10-25, 7:19 am |
| * Manoj Srivastava (srivasta@debian.org) [061025 08:04]:
> [...]
Manoj, I'm seriously asking you if we can delay this discussion until
after Etch is out. I'm very interessted in takeing part in the
discussion, but I really have already to many open very urgent tasks at
my hands.
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Raphael Hertzog 2006-10-25, 7:19 am |
| Hi,
On Wed, 25 Oct 2006, Andreas Barth wrote:
> * Manoj Srivastava (srivasta@debian.org) [061025 08:04]:
>
> Manoj, I'm seriously asking you if we can delay this discussion until
> after Etch is out. I'm very interessted in takeing part in the
> discussion, but I really have already to many open very urgent tasks at
> my hands.
Andreas, I understand your feeling but you have to accept that you can't
be on all fronts at the same time.
I understand we need to make concessions towards a release (like
concentrating on fixing bugs instead of introducing new major upstream
changes) but it shouldn't block Debian's progress in all areas.
You must understand that if Manoj is not fixing the policy, he probably
won't use that time to fix RC bugs.
And in that particular case, I have the feeling that Manoj has taken into
account the remarks of the RM since he removed the problematic parts
for now, and loosened some must into should in order to better fit
the RM conception of 'release critical'.
Manoj, I have reviewed your patch and it looks ok for me. I haven't
checked its completeness (wrt etch_release_policy.txt) however.
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Joerg Jaspert 2006-10-25, 7:19 am |
| | |
| Frank Küster 2006-10-25, 7:19 am |
| Raphael Hertzog <hertzog@debian.org> wrote:
> I understand we need to make concessions towards a release (like
> concentrating on fixing bugs instead of introducing new major upstream
> changes) but it shouldn't block Debian's progress in all areas.
> You must understand that if Manoj is not fixing the policy, he probably
> won't use that time to fix RC bugs.
That's quite correct, but it seems strange that resynchronizing of two
documents takes place while the group who authored one of them is too
busy to take part in that process.=20=20
I would hope that in this process, not only policy is improved, but also
the release-policy (if not in meaning then at least in wording and
clearness), but we can't expect this to happen right now.
Regards, Frank
--=20
Dr. Frank K=FCster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Z=
=FCrich
Debian Developer (teTeX/TeXLive)
| |
| Margarita Manterola 2006-10-25, 1:28 pm |
| On 10/25/06, Manoj Srivastava <srivasta@debian.org> wrote:
> 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').
It would be nice to have a comment, footnote or similar thing that
explains the differences between all these indicators:
Something like this:
* must / have to: you have to do this, no matter what.
* should / ought to: it's a very good idea to do this, but in some
special cases you might have a reason not to.
I don't know if these are the meanings intended. All these verbs
sound the same to me, but it seems they are intended to have different
meanings, and I think it's better to make things as clear as possible.
--
Besos,
Marga
--
To UNSUBSCRIBE, email to debian-policy-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Manoj Srivastava 2006-10-25, 1:28 pm |
| On Wed, 25 Oct 2006 09:35:13 +0200, Andreas Barth <aba@not.so.argh.org> said:
> * Manoj Srivastava (srivasta@debian.org) [061025 08:04]:
[vbcol=seagreen]
> Manoj, I'm seriously asking you if we can delay this discussion
> until after Etch is out. I'm very interessted in takeing part in the
> discussion, but I really have already to many open very urgent tasks
> at my hands.
You do not have to worry about any action being taken on this
issue; by FTP master action, uploads to policy are now verboten until
post etch anyway. Is there any harm in refining the changes and
building consensus over time? The change document can exist as a
talking point, and you can still come in and provide us your input
when you have time (post etch).
manoj
--
"I couldn't remember things until I took that Sam Carnegie course."
Bill Peterson, former Houston Oiler football coach
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Frank Küster 2006-10-25, 1:28 pm |
| Manoj Srivastava <srivasta@debian.org> wrote:
> Is there any harm in refining the changes and
> building consensus over time? The change document can exist as a
> talking point, and you can still come in and provide us your input
> when you have time (post etch).
Personally, I would see it as a waste of time to take part in a
discussion in which one of the involved parties is not involved (due to
time constraints). And that's going to be my last public mail about
this topic...
Regards, Frank
--=20
Dr. Frank K=FCster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Z=
=FCrich
Debian Developer (teTeX/TeXLive)
| |
| Manoj Srivastava 2006-10-25, 1:28 pm |
| On Wed, 25 Oct 2006 10:35:07 -0300, Margarita Manterola <margamanterola@gmail.com> said:
> On 10/25/06, Manoj Srivastava <srivasta@debian.org> wrote:
[vbcol=seagreen]
> It would be nice to have a comment, footnote or similar thing that
> explains the differences between all these indicators:
> Something like this:
> * must / have to: you have to do this, no matter what.
> * should / ought to: it's a very good idea to do this, but in some
> special cases you might have a reason not to.
> I don't know if these are the meanings intended. All these verbs
> sound the same to me, but it seems they are intended to have
> different meanings, and I think it's better to make things as clear
> as possible.
The only normative words are MUST, SHOULD, MAY, and
RECOMMENDED. I am considering using upper case where we expect
conformance.
"ought to" is a phrase used when doing something is a good
idea, but not doing so does not result in a bug on a
package. Consider the case when a ftp repository pool contains more
than one source version of a package. If you get a diff.gz file from
one version, and an orig.tar.gz file from another version, the
results might not be something that builds.
<p>
As it exists on the FTP site, a Debian source package
- consists of three related files. You must have the right
+ consists of three related files. You need to have the right
versions of all three to be able to use them.
</p>
The use of must could have been confusing, changing the phrase
to you have to tells the user that not following the "get all files
from the same source version" is a great idea, butif a user does not
do so, no serious bug needs to be filed 
manoj
--
lisp, v.: To call a spade a thpade.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-policy-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Luk Claes 2006-10-25, 1:28 pm |
| Manoj Srivastava wrote:
> Dear Luk,
>
> On Wed, 25 Oct 2006 08:16:59 +0200, Luk Claes <luk@debian.org> said:
>
>
>
>
>
> The next time you feel the urge to be patronizing, ponder on
> these:
> a) what gives you the right to pontificate and tell people what to
> do from your high horse?
Look who's talking...
> b) Why do you think getting on a soap box is likely to help
> anything, including a dialogue on this list?
I don't understand this sentence: 'getting on a soap box'?
> c) that for some of us doing things right trumps releasing on some
> arbitrary deadline hands down?
Same for 'trumps' in previous sentence.
> Part of doing things right it to lick the technical policy in
> shape; reviewing the must directives for bloat has been long
> overdue. If the policy is so far from reality that release managers
> do not consider violation of must directives as something that would
> compromise the high standards of what Debian considers fit for
> release, then it seems to me we need to fix policy.
You keep putting things in the release managers' mouth... It's not because in
some cases the must in policy isn't considered RC that release managers think
violation of must directives is ok to release with in general...
> Now, if you can stop lecturing and review the changes, and
> provide feedback on whether my judgement for thechanges is on the
> right path, you would be helping. If noit, could you please let the
> rest of us work on getting a better technical policy out?
I don't like the timing at all. As you said above it's long overdue, so I
don't see why it should happen near release time?
Cheers
Luk
--
Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D
Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D
| |
| Luk Claes 2006-10-25, 1:28 pm |
| Joerg Jaspert wrote:
> On 10818 March 1977, Luk Claes wrote:
>
>
> No, the release is no reason to stop everything else.
>
It was not meant that way at all. I just don't like that people start to
discuss topics that are long overdue near release time...
Cheers
Luk
--
Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D
Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D
| |
| Manoj Srivastava 2006-10-25, 1:28 pm |
| On Wed, 25 Oct 2006 16:08:36 +0200, Frank Küster <frank@debian.org> said:
> Manoj Srivastava <srivasta@debian.org> wrote:
[vbcol=seagreen]
> Personally, I would see it as a waste of time to take part in a
> discussion in which one of the involved parties is not involved (due
> to time constraints). And that's going to be my last public mail
> about this topic...
I see this as a long process, and by no means do I want to
exclude any one. There are a number of low hanging errors that can
be eliminated before we get to the more complex cases where we need
to get the input of everyone.
Also, consider the fact that in a project this size, there is
probably no time that is good enough for every one. By starting the
refinement now, and taking our time to get it right (I do not have an
arbitrary deadline before which policy must be fixed and rushed out
of the door), we are more likely to get a document that is in good
shape.
If you think you can only participate in the process after
Etch is released, that is fine. Policy is not going anywhere.
manoj
--
You don't move to Edina, you achieve Edina. Guindon
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Manoj Srivastava 2006-10-25, 1:28 pm |
| On Wed, 25 Oct 2006 18:51:26 +0200, Luk Claes <luk@debian.org> said:
> Joerg Jaspert wrote:
[vbcol=seagreen]
> It was not meant that way at all. I just don't like that people
> start to discuss topics that are long overdue near release time...
In a project this size, not all activities come to a dead end
every couple of years for a few months. Consistent with releasing,
activities geared towards improving the infrastructure, subsystems,
and packages can and should still be on going.
The reason I have initiated this at this point is that I was
not aware that policy is perceived to be so far out of whack with the
project processes that violations of MUST directives in policy are
considered to be unrelated to bugs serious enough to warrant
fixing -- and that policy directives linking ciolations to bug
severities are now considered an unreported bug in policy itself.
I realized that there never has been a comprehensive review
of the MUST/SHOULD/MAY dictums in policy, and also, policy has grown
organically, since until recently there was no single cohesive
editor -- the old piecemeal approach of any small group of developers
just adding language for each policy change leads to a disjoint,
incoherent document. It is about time we started looking at policy
holistically. That was the trigger.
Also, consider the fact that we are all (for the most part),
volunteers. there a re number of demands on our time. Real life
intervenes. Private and pet projects go hot or cold. the release
process is just one such drain on our timel but there are others.
For a process like a broad review of policy, where one needs to get
the buy in and eye balls of a large group of developers, it is
impossible to pick a time that is convenient for every one.
Unlike Etch, there is no pressing directive that policy review
be all done by Dec 4rth; we can and should take our time and do
this _right_. Correctness and completeness should be preferred over
speed at this point.
manoj
--
"Can you program?" "Well, I'm literate, if that's what you mean!"
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Kurt Roeckx 2006-10-25, 1:28 pm |
| 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
--
To UNSUBSCRIBE, email to debian-policy-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Manoj Srivastava 2006-10-25, 7:15 pm |
| 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:
[vbcol=seagreen]
> 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.
Harmful> /em>, one of the <tt>comp.unix.*</tt> FAQs, which[vbcol=seagreen]
[vbcol=seagreen]
> 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
--
Happy indeed we live who are free from disease among those still
diseased. In the midst of diseased men, we live free from disease. 198
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Kurt Roeckx 2006-10-25, 7:15 pm |
| On Wed, Oct 25, 2006 at 01:49:03PM -0500, Manoj Srivastava wrote:
>
>
> 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.
If it's not supposed to be used by an other package, it should be moved
to /usr/lib/package/. If it doesn't contain any other libraries in
/usr/lib, it shouldn't provide a -dev package. So there really isn't a
need for a seperate lib package either.
Anyway, that's why it says "should" in the first place, and I don't see
why it needs to be changed.
Kurt
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Luk Claes 2006-10-25, 7:15 pm |
| Manoj Srivastava wrote:
> On Wed, 25 Oct 2006 18:51:26 +0200, Luk Claes <luk@debian.org> said:
>
>
>
> In a project this size, not all activities come to a dead end
> every couple of years for a few months. Consistent with releasing,
> activities geared towards improving the infrastructure, subsystems,
> and packages can and should still be on going.
Indeed, though starting such discussions near release time is unfortunateat
the least...
> The reason I have initiated this at this point is that I was
> not aware that policy is perceived to be so far out of whack with the
> project processes that violations of MUST directives in policy are
> considered to be unrelated to bugs serious enough to warrant
> fixing -- and that policy directives linking ciolations to bug
> severities are now considered an unreported bug in policy itself.
I rather see policy as a guideline for long term compliance, but the etchRC
policy for short term compliance. Of course there are some bugs in policyand
it's indeed a good idea to review the consitency, but I think you overreact
when you say that must directives in policy are unrelated to serious bugs...
> Also, consider the fact that we are all (for the most part),
> volunteers. there a re number of demands on our time. Real life
> intervenes. Private and pet projects go hot or cold. the release
> process is just one such drain on our timel but there are others.
Right, though a release should be a common goal. It should be a joined effort...
> For a process like a broad review of policy, where one needs to get
> the buy in and eye balls of a large group of developers, it is
> impossible to pick a time that is convenient for every one.
Sure, but that's something else than not a really good time for anyone...
> Unlike Etch, there is no pressing directive that policy review
> be all done by Dec 4rth; we can and should take our time and do
> this _right_. Correctness and completeness should be preferred over
> speed at this point.
This is true for release work too, but the time between releases should be
manageable. If we release on Dec 4th with nasty bugs, I'd rather have we
release at middle or end of december without these nasty bugs...
Sorry if my message came across too harsh, but I do think quality of the
release is more important than quality of the policy at the moment and not
only because I'm on the release team, but because I as a user want to still be
proud to be part of Debian after Dec 4th :-)
Cheers
Luk
--
Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D
Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D
| |
| Roland Mas 2006-10-25, 7:15 pm |
| Luk Claes, 2006-10-25 18:51:26 +0200 :
> It was not meant that way at all. I just don't like that people
> start to discuss topics that are long overdue near release time...
Topics that are long overdue should, by definition, be discussed and
worked on *now*, regardless of whether "now" happens to be (presented
as) close to release time.
Roland.
--
Roland Mas
LinkedIn profile: http://www.linkedin.com/in/rolandmas
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Andreas Barth 2006-10-25, 7:15 pm |
| * Roland Mas (lolando@debian.org) [061025 22:38]:
> Luk Claes, 2006-10-25 18:51:26 +0200 :
>
>
> Topics that are long overdue should, by definition, be discussed and
> worked on *now*, regardless of whether "now" happens to be (presented
> as) close to release time.
Changing the release policy is obviously a non-possibility now.
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Manoj Srivastava 2006-10-25, 7:15 pm |
| On Wed, 25 Oct 2006 22:39:14 +0200, Andreas Barth <aba@not.so.argh.org> said:
> * Roland Mas (lolando@debian.org) [061025 22:38]:
[vbcol=seagreen]
> Changing the release policy is obviously a non-possibility now.
Quite so. But getting a handle on policy flaws and creating a
list of issues that need clarification can start now -- assuming, of
course, that the people working on this do not let it hamper their
efforts directed at improving release quality.
manoj
--
No question is so difficult as one to which the answer is obvious.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Anthony Towns 2006-10-26, 1:33 am |
| On Wed, Oct 25, 2006 at 09:20:34AM -0500, Manoj Srivastava wrote:
> The only normative words are MUST, SHOULD, MAY, and
> RECOMMENDED. I am considering using upper case where we expect
> conformance.
Didn't the definitions of MUST/SHOULD/MAY get removed in your patch though?
Cheers,
aj
| |
| Kevin Mark 2006-10-26, 1:33 am |
| On Wed, Oct 25, 2006 at 10:39:14PM +0200, Andreas Barth wrote:
> * Roland Mas (lolando@debian.org) [061025 22:38]:
>
> Changing the release policy is obviously a non-possibility now.
>
Hi,
there is the policy manual and release policy. Is not Manoj discussing
changes to the former? if the policy manual is in a document
repositories, anyone can reference a certain version from the past as
applying to release policy while changes are introduced.
cheers,
Kev
--
| .''`. == Debian GNU/Linux == | my web site: |
| : :' : The Universal | debian.home.pipeline.com |
| `. `' Operating System | go to counter.li.org and |
| `- http://www.debian.org/ | be counted! #238656 |
| my keysever: pgp.mit.edu | my NPO: cfsg.org |
| |
| Steve Langasek 2006-10-26, 1:33 am |
| On Wed, Oct 25, 2006 at 01:49:03PM -0500, Manoj Srivastava wrote:
[vbcol=seagreen]
[vbcol=seagreen]
> 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.
However, I think it's important that policy outline those cases in which
it's not a bug to omit a .config script. Doesn't the absence of the .config
script require additional by-hand handling of the templates which is
otherwise done automatically through apt?
[vbcol=seagreen]
[vbcol=seagreen]
> 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.
This tells me that the guidelines for when shared library packages must be
split up are still ill-defined in some corner cases. I don't think we
should be gutting such an important requirement from policy just because
there may be corner cases that need sorting, when the cost of non-compliance
with this requirement is so high.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vorlon@debian.org http://www.debian.org/
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Manoj Srivastava 2006-10-26, 1:33 am |
| On Thu, 26 Oct 2006 10:44:53 +1000, Anthony Towns <aj@azure.humbug.org.au> said:
> On Wed, Oct 25, 2006 at 09:20:34AM -0500, Manoj Srivastava wrote:
[vbcol=seagreen]
> Didn't the definitions of MUST/SHOULD/MAY get removed in your patch
> though?
It did in the first draft. Based on feedback, a modified
version was re-introduced in the second draft, which ought to meet
the flexibility requirements mentioned by the release managers.
manoj
--
Backed up the system lately?
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Manoj Srivastava 2006-10-26, 1:33 am |
| On Wed, 25 Oct 2006 19:44:38 -0700, Steve Langasek <vorlon@debian.org> said=
:=20
> On Wed, Oct 25, 2006 at 01:49:03PM -0500, Manoj Srivastava wrote:
[vbcol=seagreen]
[vbcol=seagreen]
[vbcol=seagreen]
=20[vbcol=seagreen]
> However, I think it's important that policy outline those cases in
> which it's not a bug to omit a .config script.
I don't think I know _all_ use cases in which it is ok not to
add a .config file. I can provide a few use cases. I think the reader
should be allowed to make their own judgement calls, in case they
have a use case we might miss.
> Doesn't the absence of the .config script require additional by-hand
> handling of the templates which is otherwise done automatically
> through apt?
No. From debconf-devel (7):
,----
| A question is an instantiated template. By asking debconf to display a
| question, your config script can interact with the user. When debconf
| loads a templates file (this happens whenever a config or postinst
| script is run), it automatically instantiates a question from each tem=
=E2=80=90
| plate. It is actually possible to instantiate several independent ques=
=E2=80=90
| tions from the same template (using the REGISTER command), but that is
| rarely necessary.=20
`----
[vbcol=seagreen]
[vbcol=seagreen]
[vbcol=seagreen]
> This tells me that the guidelines for when shared library packages
> must be split up are still ill-defined in some corner cases. I
> don't think we should be gutting such an important requirement from
> policy just because there may be corner cases that need sorting,
> when the cost of non-compliance with this requirement is so high.
Making a SHOULD directive a suggestion is hardly what I call
gutting. However, since this is one area I was fuzzy about, and now I
have seen two strong negative reactions, and none in favour, this
seems like something that may be reverted.
manoj
--=20
"The Nazis have no sense of humor, so why should they want
television?" Philip K. Dick
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
| |
| Josselin Mouette 2006-10-26, 7:17 am |
| Le mercredi 25 octobre 2006 =E0 01:03 -0500, Manoj Srivastava a =E9crit :
> Here is a first draft of changes to the policy that I think
> are required to bring ot closer in line with extant practice. I
> removed portions from the policy that linked policy violations to bug
> severities, since this has been deemed controversial and a "bug" in
> policy. Next, I removed the DFSG text and replaced it by a pointer
> to the DFSG document itself, this prevents duplication, and I am not
> sure I would have remembered to edit it here if we ever changed the
> DFSG.
FWIW, I strongly disagree with these changes. The solution is to bring
the release policy in line with the real policy, not the opposite.
--=20
.''`. Josselin Mouette /\./\
: :' : josselin.mouette@ens-lyon.org
`. `' joss@debian.org
`- Debian GNU/Linux -- The power of freedom
| |
| Marco d'Itri 2006-10-26, 1:15 pm |
| On Oct 26, Josselin Mouette <joss@debian.org> wrote:
> FWIW, I strongly disagree with these changes. The solution is to bring
> the release policy in line with the real policy, not the opposite.
Yes, and let's forget about this "reality" bullshit...
--
ciao,
Marco
| |
| Neil McGovern 2006-10-28, 7:24 am |
| On Thu, Oct 26, 2006 at 10:31:01AM +0200, Josselin Mouette wrote:
> Le mercredi 25 octobre 2006 à 01:03 -0500, Manoj Srivastava a écrit :
>
> FWIW, I strongly disagree with these changes. The solution is to bring
> the release policy in line with the real policy, not the opposite.
>
Seconded, with adding a note that this should all be looked at AFTER
etch is released. It's too late now to go making major changes to policy
or the release policy.
Neil
--
<Yoe> is _that_ gunnar?
<weasel> yes
<Yoe> what happened to his tires?
<towersbe> He's shrunk. I think his wife washed him at too high a temperature.
| |
| Russ Allbery 2006-10-28, 7:41 pm |
| Manoj Srivastava <srivasta@debian.org> writes:
> On Wed, 25 Oct 2006 20:01:32 +0200, Kurt Roeckx <kurt@roeckx.be> said:
[vbcol=seagreen]
[vbcol=seagreen]
[vbcol=seagreen]
> This flows from the Release policy. Not specifying /bin/bash
> in scripts is not considered a RC bug.
I can try to propose better language for this. I think that using pure
bash-specific constructs not found in dash in /bin/sh scripts should
actually be an RC bug, but using test -a or test -o should not. I think
we need to say that /bin/sh scripts are permitted to use POSIX shell
capabilities plus a short list of additional capabilities that everything
other than posh also implement.
> Harmful> /em>, one of the <tt>comp.unix.*</tt> FAQs, which
[vbcol=seagreen]
[vbcol=seagreen]
> 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.
Here, I'm dubious that this really isn't RC. I think the only reason why
this isn't listed in the RC criteria is because csh scripts are so rare
that there's no reason to single it out. If a csh script does not start
with /bin/csh (or name some specific csh implementation; maybe there's an
opportunity for wording improvement) or doesn't depend on c-shell, it's
broken and won't work on a Debian system. That sounds rather RC to me.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Bill Allombert 2006-10-29, 7:23 pm |
| On Wed, Oct 25, 2006 at 01:03:11AM -0500, Manoj Srivastava wrote:
> @@ -113,36 +113,6 @@
> either. Please see <ref id="pkg-scope"> for more information.
> </p>
>
> - <p>
> - In the normative part of this manual,
> - the words <em>must</em>, <em>should</em> and
> - <em>may</em>, and the adjectives <em>required</em>,
> - <em>recommended</em> and <em>optional</em>, are used to
> - distinguish the significance of the various guidelines in
> - this policy document. Packages that do not conform to the
> - guidelines denoted by <em>must</em> (or <em>required</em> )
> - will generally not be considered acceptable for the Debian
> - distribution. Non-conformance with guidelines denoted by
> - <em>should</em> (or <em>recommended</em> ) will generally be
> - considered a bug, but will not necessarily render a package
> - unsuitable for distribution. Guidelines denoted by
> - <em>may</em> (or <em>optional</em> ) are truly optional and
> - adherence is left to the maintainer's discretion.
> - </p>
I would suggest we use uppercase[1] to denote must, should, may and
required, recommended, optional to denote the normative usage. This
way we could still use the lowercase word for non-normative usage.
at the very least, this would reduce the size of the proposed diff.
[1] or any typographical distinction that can represented in the
plain text version.
Cheers,
--
Bill. <ballombe@debian.org>
Imagine a large blue swirl here.
--
To UNSUBSCRIBE, email to debian-policy-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Anthony Towns 2006-10-30, 1:24 am |
| On Sat, Oct 28, 2006 at 12:58:34PM -0700, Russ Allbery wrote:
> If a csh script does not start
> with /bin/csh (or name some specific csh implementation; maybe there's an
> opportunity for wording improvement) or doesn't depend on c-shell, it's
> broken and won't work on a Debian system. That sounds rather RC to me.
If it were the only thing in a package it would be grave, but if it's
just a random script no one actually uses, it would just be a minor/normal
bug, afaics.
Cheers,
aj
|
|
|
|
|