Bug#758234: debian-policy: allow packages to depend on packages of lower priority

[Russ Allbery]

Charles Plessy  writes:

> First, minor point, but I think that #196367 (Clarify Policy on priority
> inversion in dependencies) can also be closed by the changes.

Thank you!

> Second, I would like to propose one more clarification to the
> description of the "Important" priority.

I believe this is #776557 (and kind of unrelated to this discussion).
Maybe move this discussion there?  There's already been a fair bit of
(rather inconclusive) discussion on that bug.

-- 
Russ Allbery (r...@debian.org)   

Bug#758234: debian-policy: allow packages to depend on packages of lower priority

[Charles Plessy]

Le Sun, Jul 02, 2017 at 01:39:13PM -0700, Russ Allbery a écrit :
> Control: tags -1 = pending
> Control: tags 759260 = pending
> Control: tags 660249 = pending
 
> The upgrading-checklist entry for this change:
> 
>   
> Priorities are now used only for controlling which packages
> are part of a minimal or standard Debian installation and
> should be selected based on functionality provided directly to
> users (so nearly all shared libraries should have a priority
> of optional).  Packages may now depend on
> packages with a lower priority.
>   
>   
> The extra priority has been deprecated and
> should be treated as equivalent to
> optional.  All extra
> priorities should be changed to optional.
> Packages with a priority of optional may
> conflict with each other (but packages that both have a
> priority of standard or higher still may
> not conflict).
>   

Thanks Russ and everybody who made it happen.

I am a bit late, but I would like to make two comments.

First, minor point, but I think that  #196367 (Clarify Policy on priority
inversion in dependencies) can also be closed by the changes.

Second, I would like to propose one more clarification to the description
of the "Important" priority.  At the moment, it contains the following:

"If the expectation is that an experienced Unix person who found it missing
would say "What on earth is going on, where is foo?", it must be an 
important
package. [Footnote: This is an important criterion because we are trying to
produce, amongst other things, a free Unix.]"

This has been written roughly 20 years ago and I think that as of today,
the diversity of experiences and evolutions of "Unix" make this definition
very hard to follow.  Also, it makes the difference between "important" and
"standard" quite blurry and matter of taste and opinions.

In contrast, the definition of "required" is very straigthforward: the bare
minimum needed to run dpkg.  Interstingly, after a quick look at the list of
"important" packages, I have the impression that they are close to the minimum
needed to run apt over the network.  If you agree with my analysis, I think
that the Policy would be clearer with this alternative definition for
"important":

Packages which are necessary to run `apt` and use it to download other
packages from the network, plus the bare minimum of commonly-expected and
necessary tools to administrate the system.  This does not include
space-consuming features such as documentationa and multilingual support.

(The last sentence above is there because man-db, debian-faq and locales are
all priority:standard).

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan

Processed: user debian-pol...@packages.debian.org, limit package to debian-policy, tagging 196367

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> user debian-pol...@packages.debian.org
Setting user to debian-pol...@packages.debian.org (was r...@debian.org).
> limit package debian-policy
Limiting to bugs with field 'package' containing at least one of 'debian-policy'
Limit currently set to 'package':'debian-policy'

> tags 196367 = pending
Bug #196367 [debian-policy] Clarify Policy on priority inversion in dependencies
Added tag(s) pending.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
196367: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=196367
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#849853: [debian-policy] Document source-is-missing lintian kind of problems

[Russ Allbery]

Sean Whitton  writes:

> Policy currently defers to the DFSG for a definition of what counts as
> free software for Debian's purposes.  Thanks to the DPL's delegation of
> the ftp-masters, Policy defers to the DFSG plus the ftp-masters jointly.

> If we included text in Policy about common ways in which a package could
> fail to satisfy DFSG, Policy would effectively cease to defer to the
> ftp-masters.  I don't think that Policy has the authority to do that,
> and I don't think it would be desirable.

Agreed.  This area is also fairly controversial and fluid, whereas Policy
(at least right now) is very static and slow-moving, so I think we would
run a very high risk of incorporating rules that the project then changes
and thereby adding to the confusion.

> A footnote with a link to the REJECT-FAQ sounds useful.  Here's a patch.

As much as I don't like footnotes, this does seem like a good use of one.
I second your patch (not that I really need to since it's informative).
Seems like a good thing to merge.

-- 
Russ Allbery (r...@debian.org)   

Bug#849851: [debian-policy] Document that rules clean target is not sufficient for removing dfsg problems

[Russ Allbery]

Sean Whitton  writes:

> I don't think that it should be a point of Policy that the rules clean
> target is not to be used for this purpose, because it is entailed by the
> ftp-master's interpretation of DFSG plus this sentence that we already
> have in Policy:

> Every [source or binary] package in main must comply with the DFSG
> (Debian Free Software Guidelines).

Well, if it's a common-enough error, I think there's no problem with also
mentioning this in the section on the clean rule.  It's not likely that
this interpretation is going to change.

> However, as you say, we should document this to prevent others from
> tripping over it.  As you suggest, such a note would need to refer to
> repacking the tarball.  The Developer's Reference already contains a
> discussion of repacking upstream tarballs, so perhaps this should go
> there?

+1 on putting any detailed instructions in the Developer's Reference
rather than in Policy, unless someone wants to tackle documenting upstream
source repackaging and the upstream version number convention in Policy
directly (which isn't the worst idea, but probably isn't hugely urgent).

> Or we could use a footnote to Policy.  I attach a patch doing that.

I'm on a war against footnotes in Policy because I think they make it much
harder to read (particularly in text form, particularly with DocBook which
now moves all the footnotes to the end of the chapter).  I'd love to move
them all to either inline text or sidebars of some kind, although that's
going to be a long effort.

> diff --git a/policy.xml b/policy.xml
> index 782bd88..303688b 100644
> --- a/policy.xml
> +++ b/policy.xml
> @@ -2170,6 +2170,16 @@
>build has been invoked as root (since
>build may create directories, for
>example).
> +  
> +
> +  The clean target should not be used to remove files
> +  in the source tree that are not compatible with the
> +  DFSG.  This is because the files would remain in the
> +  upstream tarball, and thus in the source package, so
> +  the source package would continue to violate DFSG.
> +  Instead, the upstream source should be repacked.
> +
> +  
>  
>
>  

s/should not/cannot/ (to get away from using standards language here and
because this isn't a Policy statement so much as a statement of
capability), and I would say "repacked to remove those files" in the last
sentence, but otherwise this looks good to me and could just be included
directly in that section on clean, I think.

-- 
Russ Allbery (r...@debian.org)   

Re: Proposal: move forward to Sphinx

[Russ Allbery]

Hideki Yamane  writes:
> Russ Allbery  wrote:

>> 1. We've always had reasonably good PDF output, and I want to maintain
>>that.  I'm not sure how good Sphinx's pipeline is for that, and as
>>noted in the slides that would need to be tested.  (ePub might be
>>better than PDF at this point, though.)

>  Let's check it.
>  See http://www.ma-aya.to/~henrich/debian/policy/DebianPolicyManual.pdf

That looks pretty good!  Certainly no worse than what we have now.

>> 2. I don't think the Policy Editors probably have time to help a ton with
>>the conversion, so it would need to be driven by someone else with time
>>to rebase it repeatedly (probably by writing conversion scripts),
>>similar to what was done with the DocBook conversion.  We'd also want
>>all documents in Policy to be moved to restructured text (except the
>>pure text ones) so that we are on a single format as a result of this
>>change.

>  I'll care it, of course :) But I'm not sure all conversions can be done
>  at once, it takes time and some effort.

The approach that Guillem took with the DocBook conversion is to tune a
script that did all the conversions until it could handle all of the
documents, and then we were able to do that conversion all at once in one
release.  That's ideal, but certainly understood if you want to merge some
partial results first.

>> 3. Historically, text-like formats have struggled with multiply-nested
>>lists with multi-paragraph blocks and embedded literal blocks.  The
>>output from Sphinx looks surprisingly good, so maybe its version of
>>reStructured Text does address all of this.  But we'd want to verify
>>that we can get reasonable results from fairly complex structure.
>>(There seems to be something weird going on with fonts in definition
>>lists in your sample output, for instance.)

>  You mean 
> http://www.ma-aya.to/~henrich/debian/policy/ch-controlfields.html#list-of-fields
>  ?
>  Some weird looking can be adjust with modifying Sphinx theme, I guess. 

I was looking at:

http://www.ma-aya.to/~henrich/debian/policy/ch-maintainerscripts.html#summary-of-ways-maintainer-scripts-are-called

but that was a disaster in various formats in DocBook as well.  I'm
curious to see if it will be any better now since I significantly changed
the representation in DocBook to try to get better text output (and
somewhat better HTML output).

>> 4. We'd like to be able to divide documents into multiple source files for
>>ease of editing (I kind of want to do that with Policy, and we're doing
>>that now for the debconf specification).  I'm not sure if Sphinx
>>supports this?

>  I had splitted policydoc to restructuredtext on each chapter.
>  https://github.com/henrich/policydoc/tree/restructure/source

Oh, beautiful.  Yup, that's what I meant!

>  What does "multiple source" mean (Including other file)?
>  If so, "include" directive would help. I'll test it later.
>  http://docutils.sourceforge.net/docs/ref/rst/directives.html#include

I think only the debconf specification uses that, but if that's supported,
that's great.

>  Sphinx supports some directives like "tip", "warning", "note", etc.
>  See http://docutils.sourceforge.net/docs/ref/rst/directives.html#tip

Oh, excellent!  No current examples, but the existence of this definitely
puts my mind at ease.

>  Yes, once I thought about Publican, it is also nice but little bit
>  tough to use, perhaps we need some people to maintain it with lots
>  effort. Sphinx is not so complicated and if other toolchain that can
>  deal with restructuredtext is better than Sphinx, we can move to it.

Yeah, I think reStructured Text is such a huge usability win and will make
it so much easier for people to propose language that we should just go
for it.

-- 
Russ Allbery (r...@debian.org)   

Re: RFC: draft text for Policy sprint at DebCamp

[Russ Allbery]

Sean Whitton  writes:
> On Sat, Jun 24, 2017 at 03:48:35PM -0700, Russ Allbery wrote:

>> Looks great to me!  And we're probably coming up on time for that new
>> d-d-a email.

> I've created Teams/Policy/bits on gobby.debian.org to draft this.  I've
> written some text about the sprint.  Perhaps you could write up the
> introduction, Russ, since you have a clearer idea of the purpose of this
> d-d-a e-mail than I do.

I made a few tweaks and added a note about 4.0.0 to the introduction, but
it otherwise looked great to me.  Thanks for drafting this!

-- 
Russ Allbery (r...@debian.org)   

Re: Bug#758234: debian-policy: allow packages to depend on packages of lower priority

[Andrey Rahmatullin]

On Sun, Jul 02, 2017 at 01:39:13PM -0700, Russ Allbery wrote:
>   
> 2.5
> 
>   
> Priorities are now used only for controlling which packages
> are part of a minimal or standard Debian installation and
> should be selected based on functionality provided directly to
> users (so nearly all shared libraries should have a priority
> of optional).  Packages may now depend on
> packages with a lower priority.
>   
>   
> The extra priority has been deprecated and
> should be treated as equivalent to
> optional.  All extra
> priorities should be changed to optional.
> Packages with a priority of optional may
> conflict with each other (but packages that both have a
> priority of standard or higher still may
> not conflict).
>   
> 
>   
Thank you everyone involved!

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#866192: Broken Link in Policy HTML Page

[Russ Allbery]

Sean Whitton  writes:

> I've taken a stab at this, in branch bug866192-spwhitton of
> debian-policy.git repo.  Reviews very welcome.

This looks good to me.  Thanks!

-- 
Russ Allbery (r...@debian.org)   

Bug#640263: debian-policy: Clarify policy section 9.9 - Environment variables

[Russ Allbery]

Control: tags -1 = pending

Niels Thykier  writes:
> On Sun, 25 Jun 2017 14:58:06 -0700 Russ Allbery  wrote:

>> Everyone seemed generally happy with this text, but it never clearly got
>> enough seconds to apply.  Here's an updated patch so that we can take
>> another run at getting enough seconds and getting it merged.

> Seconded,  thanks for writing it. :)

Thanks, both.  This has now been applied for the next release.

-- 
Russ Allbery (r...@debian.org)   

Processed: Re: Bug#640263: debian-policy: Clarify policy section 9.9 - Environment variables

[Debian Bug Tracking System]

Processing control commands:

> tags -1 = pending
Bug #640263 [debian-policy] Clarify 9.9 - Environment variables
Added tag(s) pending; removed tag(s) patch.

-- 
640263: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640263
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: Re: Bug#758234: debian-policy: allow packages to depend on packages of lower priority

[Debian Bug Tracking System]

Processing control commands:

> tags -1 = pending
Bug #758234 [debian-policy] Allow packages to depend on packages of lower 
priority
Bug #769273 [debian-policy] Allow packages to depend on packages of lower 
priority
Added tag(s) pending; removed tag(s) patch.
Added tag(s) pending; removed tag(s) patch.
> tags 759260 = pending
Bug #759260 [debian-policy] Remove priority "extra", make all corresponding 
packages priority "optional"
Added tag(s) pending; removed tag(s) patch.
> tags 660249 = pending
Bug #660249 [debian-policy] reword reasons for a package to be priority: extra
Added tag(s) pending.

-- 
660249: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660249
758234: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758234
759260: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=759260
769273: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769273
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#758234: debian-policy: allow packages to depend on packages of lower priority

[Russ Allbery]

Control: tags -1 = pending
Control: tags 759260 = pending
Control: tags 660249 = pending

I've merged this patch for the next release.  The only change from my
proposed wording was that I added this sentence to the description of
extra, just to be clear how to treat any packages found in the wild with
that priority:

This priority should be treated as equivalent to optional.

I don't think this will change anything, but it seemed best to be clear.

The upgrading-checklist entry for this change:

  
2.5

  
Priorities are now used only for controlling which packages
are part of a minimal or standard Debian installation and
should be selected based on functionality provided directly to
users (so nearly all shared libraries should have a priority
of optional).  Packages may now depend on
packages with a lower priority.
  
  
The extra priority has been deprecated and
should be treated as equivalent to
optional.  All extra
priorities should be changed to optional.
Packages with a priority of optional may
conflict with each other (but packages that both have a
priority of standard or higher still may
not conflict).
  

  

-- 
Russ Allbery (r...@debian.org)   

Bug#866192: Broken Link in Policy HTML Page

[Sean Whitton]

control: tag -1 +patch

On Tue, Jun 27, 2017 at 10:16:16PM -0700, Russ Allbery wrote:
> * Ask debian-www to publish the HTML version of that file as well.
> * Change the link to point to the wiki version of the file.
> * Convert the process doc to DocBook so that we can make it an appendix.
> 
> I'm kind of leaning towards the last, honestly.

I've taken a stab at this, in branch bug866192-spwhitton of
debian-policy.git repo.  Reviews very welcome.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Processed: Re: Broken Link in Policy HTML Page

[Debian Bug Tracking System]

Processing control commands:

> tag -1 +patch
Bug #866192 [debian-policy] debian-policy: Broken Link in Policy HTML Page
Added tag(s) patch.

-- 
866192: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866192
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#849851: [debian-policy] Document that rules clean target is not sufficient for removing dfsg problems

[Sean Whitton]

control: user debian-pol...@packages.debian.org
control: usertag -1 +discussion

Hello Bastien,

On Sun, Jan 01, 2017 at 01:37:25PM +0100, Bastien ROUCARIÈS wrote:
> Following #849830 and generally source-is-missing lintian problems
> could you document in 4.9 Main building script: debian/rules that
> clean target must no be used for removing dfsg problem but the right
> tools is repack

I don't think that it should be a point of Policy that the rules clean
target is not to be used for this purpose, because it is entailed by
the ftp-master's interpretation of DFSG plus this sentence that we
already have in Policy:

Every [source or binary] package in main must comply with the DFSG
(Debian Free Software Guidelines).

However, as you say, we should document this to prevent others from
tripping over it.  As you suggest, such a note would need to refer to
repacking the tarball.  The Developer's Reference already contains a
discussion of repacking upstream tarballs, so perhaps this should go
there?

Or we could use a footnote to Policy.  I attach a patch doing that.

-- 
Sean Whitton
From 56fab75d2c803ae9afd8d2186613713b297f9138 Mon Sep 17 00:00:00 2001
From: Sean Whitton 
Date: Sun, 2 Jul 2017 10:10:20 +0100
Subject: [PATCH] add a footnote about the clean target and DFSG repacking

---
 policy.xml | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/policy.xml b/policy.xml
index 782bd88..303688b 100644
--- a/policy.xml
+++ b/policy.xml
@@ -2170,6 +2170,16 @@
   build has been invoked as root (since
   build may create directories, for
   example).
+  
+
+  The clean target should not be used to remove files
+  in the source tree that are not compatible with the
+  DFSG.  This is because the files would remain in the
+  upstream tarball, and thus in the source package, so
+  the source package would continue to violate DFSG.
+  Instead, the upstream source should be repacked.
+
+  
 
   
 
-- 
2.11.0



signature.asc
Description: PGP signature

Bug#542288: debian-policy: Version numbering: native packages, NMU's, and binary only uploads

[Sean Whitton]

Hello Russ,

On Sat, Jul 01, 2017 at 08:52:29AM -0700, Russ Allbery wrote:
> I thought there actually was a consensus that it's terrible.  I certainly
> think it's not good practice.  I would recommend against anyone doing
> this, speaking as someone who maintains lots of upstream software that I
> also package for Debian, and therefore would rather not document it in
> Policy, unless we're going to say not to do it.

Thank you for your response.  I trust your judgement about this
consensus.  So I withdraw my comments regarding your patch.

So as not to let this bug get off-topic, I'll send you some other
comments about using native packages privately.

-- 
Sean Whitton


signature.asc
Description: PGP signature