Bug#758234: Allow packages to depend on packages of lower priority

[Jonathan Nieder]

Hi,

Adam Borowski wrote:

> What about this wording?:
>
> -  Packages must not depend on packages with lower priority values (excluding
> -  build-time dependencies). In order to ensure this, the priorities of one
> -  or more packages may need to be adjusted.
> +  Packages' priorities should depend solely on functionality they directly
> +  bring to the user; their priority should not be modified merely because
> +  another package makes use of them (this can be expressed via a
> +  dependency).  In particular, this means that C-like libraries almost never
> +  will have a priority above optional.
> +
> +  On the other hand, it is allowed to _move_ such elevation to a package
> +  that depends on the actual implementation: for example, if we ever declare
> +  postgresql-client to be important, it may be elevated despite being an
> +  empty package that merely depends on postgresql-client-9.6.

Seconded.

> Obviously, this also requires changing the "extra" priority; either by
> #759260 (complete removal) or at least:
>
> -  This contains all packages that conflict with others with
> -  required, important, standard or optional priorities, or are only
> -  likely to be useful if you already know what they are or have
> -  specialized requirements (such as packages containing only
> -  detached debugging symbols).
> +  This priority is deprecated, but may be used to denote packages
> +  that are unlikely to be useful even for most users interested
> +  in their general field.

Does this mean we're losing the requirement that two "optional" packages
are not permitted to conflict with one another?

In any event, that's probably better to discuss on bug#759260.

Thanks,
Jonathan

Bug#757760: debian-policy: please document build profiles

[Jonathan Nieder]

Hi,

Johannes Schauer wrote:

> please document the new Build-Depends syntax and fields for build
> profiles. The current write-up of the new syntax and fields for build
> profiles lives at https://wiki.debian.org/BuildProfileSpec
>
> Please note, that the new Build-Depends syntax element is called
> "restriction list" and can be used for more than build profiles. So
> documenting the new restriction list syntax and how build profiles use
> it are probably two distinct topics to cover.
>
> Please help discussing this feature so that it can become policy.
>
> A list of software which implements it is listed in the wiki link above
> and they are all part of jessie/testing already.

I'd like to restart this discussion.  My understanding is that all the
relevant infrastructure for build profiles is in place, so what's left
is to add some text to policy documenting it.

Is my understanding correct?  Any thoughts before I (or someone else)
starts to port the change-based language from
https://wiki.debian.org/BuildProfileSpec to current-state based
language in policy?

Kernel team, any notes from your experience using build profiles?

Thanks,
Jonathan

Bug#798476: Maintainer information in source packages (was: Re: Returning to the requirement that Uploaders: contain humans)

[Jonathan Nieder]

Hi,

Ansgar Burchardt wrote:

> as a more radical change one could also ask the question where to
> maintain the maintainer information.  Currently we handle this in the
> source package via the Maintainer and Uploaders field, and via team
> memberships.
>
> This has several limitations: for teams, Uploaders will often be
> useless (you don't want to list all team members in every team-
> maintained package).  The Maintainer field only really applies to
> Debian, in derivatives someone else should be contacted.  In stable
> releases, the field can often be outdated (it records who maintained
> the package some time ago, not who currently maintains it).
>
> So I have been wondering several times whether we should move the
> maintainer information elsewhere.  For example, tracker.d.o could be
> extended to record maintainer information.  It could also understand
> the concept of "teams" listing team members and whom to send mails
> about individual packages.

This would make me pretty happy, for what it's worth.

Thanks,
Jonathan

> For legacy purposes, the Maintainer field would then list ${source}@tra
> cker.d.o and the Uploaders field could be removed.
>
> This would also address the fact that various bits of our
> infrastructure don't know about Uploaders (like bugs.d.o only
> contacting the Maintainer).
>
> Ansgar

Bug#732445: debian-policy should encourage verification of upstream cryptographic signaturse

[Jonathan Nieder]

Hi,

Russ Allbery wrote:

> How does this look to everyone?

Seconded, with or without the tweaks dkg suggested in
https://bugs.debian.org/732445#68

Thanks,
Jonathan

> --- a/policy.xml
> +++ b/policy.xml
> @@ -2556,11 +2556,28 @@ endif
>  
>
>  This is an optional, recommended configuration file for the
> -uscan utility which defines how to
> +uscan utility which defines how to
>  automatically scan ftp or http sites for newly available updates
>  of the package.  This is used Debian QA tools to help with quality
>  control and maintenance of the distribution as a whole.
>
> +  
> +If the upstream maintainer of the software provides PGP signatures
> +for new releases, including the information required for
> +uscan to verify signatures for new upstream
> +releases is also recommended.  To do this, use the
> +pgpsigurlmangle option in
> +debian/watch to specify the location of the
> +upstream signature, and include the key or keys used to sign
> +upstream releases in the Debian source package as
> +debian/upstream/signing-key.asc.
> +  
> +  
> +For more information about uscan and these
> +options, including how to generate the file containing upstream
> +signing keys, see
> +
> uscan1.
> +  
>  
>  
>  
> 

Bug#872808: [debian-policy] nocheck DEB_BUILD_OPTIONS DEB_BUILD_PROFILES

[Jonathan Nieder]

Hi Bastien,

Bastien ROUCARIÈS wrote:

> I think the following patch is needed even if profiles are not fully 
> specified.
> Maybe an example about nodoc and help2man will also help. The nocheck should
> check both BUILD_OPTIONS and BUILD_PROFILES. It will help when implementing as
> policy profiles
>
> diff --git a/policy/ch-source.rst b/policy/ch-source.rst
> index f706a13..d3d868c 100644
> --- a/policy/ch-source.rst
> +++ b/policy/ch-source.rst
> @@ -465,7 +465,8 @@ The meaning of the following tags has been standardized:
>  
>  ``nocheck``
>  This tag says to not run any build-time test suite provided by the
> -package.
> +package. This tag could be also specified using
> +   ``DEB_BUILD_PROFILES`` variable with nocheck flag
> 
>  ``nodoc``
>  This tag says to skip any build steps that only generate package
> @@ -531,7 +532,7 @@ order to make it work for your package.
> 
>  build:
>  # ...
> -ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
> +ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS $DEB_BUILD_PROFILES)))
>  # Code to run the package test suite.
>  endif

I am all for starting small in documenting build profiles (perhaps by
documenting DEB_BUILD_PROFILES before the Build-Depends syntax) but it
is possible to go too small.  This patch doesn't give context for what
DEB_BUILD_PROFILES means and it makes policy harder to understand.

In other words, if a patch
- described what a build profile is
- explained the DEB_BUILD_PROFILES environment variable
- listed which values in that variable are required to be supported

then that would already be enough for me to second it.  This patch
doesn't do that.

Do you mind if I merge this with bug#757760?

Thanks,
Jonathan

Bug#683222: debian-policy: Policy section 4.4 is imprecise with respect to section 12.7

[Jonathan Nieder]

Sean Whitton wrote:
> On Wed, Aug 01, 2012 at 08:07:01AM +0900, Charles Plessy wrote:

>> Otherwise, how about something along these lines: [...]
>
> Commenting on Charles' patch, I think that it would be clearer to have
> the 'should' and 'must' requirements in separate sentences.
>
> Thus I am seeking seconds for the following patch:
>
> diff --git a/policy/ch-source.rst b/policy/ch-source.rst
> index f706a13..89b355a 100644
> --- a/policy/ch-source.rst
> +++ b/policy/ch-source.rst
> @@ -99,10 +99,11 @@ later reconfigure the package without losing the changes 
> you made.
>  Debian changelog: ``debian/changelog``
>  --
>  
> -Changes in the Debian version of the package should be briefly explained
> -in the Debian changelog file ``debian/changelog``.  [#]_ This includes
> -modifications made in the Debian package compared to the upstream one as
> -well as other changes and updates to the package.  [#]_
> +Every source package must include the Debian changelog file,
> +``debian/changelog``.  Changes in the Debian version of the package
> +should be briefly explained in this file.  [#]_ This includes
> +modifications made in the Debian package compared to the upstream one
> +as well as other changes and updates to the package.  [#]_
> 
>  The format of the ``debian/changelog`` allows the package building tools
>  to discover which version of the package is being built and find out

Seconded.  Thanks for tying up this loose end.

Sincerely,
Jonathan

Bug#872895: debian-policy: Split html for policy lost

[Jonathan Nieder]

Hi,

Sean Whitton wrote:
> On Tue, Aug 22 2017, Guillem Jover wrote:

>> This version has lost the distinction between a single policy html and
>> the one with different files per chapter. This will break links.
>
> This was intentional.  The single page output is much more useful to
> casual readers wanting to look something up.

I don't completely understand.  The old rendering had both single page
and multi-page versions.  If I understand what you're saying, it is a
reason that the single-page version is useful, but why does that
preclude also providing the multi-page rendering?

Thanks,
Jonathan

Bug#872956: [debian-policy] warn about danger of pipe in shell snippet of makefile

[Jonathan Nieder]

Hi,

Bastien ROUCARIÈS wrote:

> set -e is not suffisant to detect error in pipe context
>
> cat nonexistant | sed s/some//g will hapilly return 0 and do not fail
>
> exec 3>&1; s=$(exec 4>&1 >&3; { cat nonexistant ; echo $? >&4; } | sed 
> s/some//g ) && exit $s
>
> this could be simplified by using make function
> PIPESAFE=exec 3>&1; s=$$(exec 4>&1 >&3; { $(1) ; echo $$? >&4; } | $(2)) && 
> exit $$s
>
> Could deserve a footnote on 4.6. Error trapping in makefiles

I don't think this belongs in policy.  Maybe devref?

By the way, if you're using bash
(https://www.gnu.org/software/make/manual/html_node/Choosing-the-Shell.html),
you can use "set -o pipefail" to handle this kind of case.

Thanks,
Jonathan

Bug#682347: mark 'editor' virtual package name as obsolete

[Jonathan Nieder]

Hi,

Russ Allbery wrote:

> +++ b/policy/ch-customized-programs.rst
> @@ -93,19 +93,21 @@ page.
[...]
> -It is not required for a package to depend on ``editor`` and ``pager``,
> -nor is it required for a package to provide such virtual
> -packages. [#]_
> +Packages may assume that ``/usr/bin/editor`` and ``/usr/bin/pager`` are
> +available as fallbacks without adding an explicit package dependency, and
> +may fail if they are not present.  There are no ``editor`` or ``pager``
> +virtual packages.

One change this patch makes is to talk about /usr/bin/editor and
/usr/bin/pager files instead of editor and pager files.  Is that
intentional?

E.g. git uses "editor" as its default editor, not /usr/bin/editor.

[...]
> @@ -572,10 +574,6 @@ installed in ``/usr/share/man/man6``.
> portion is handled internally by the package system based on the os
> and cpu.
>  
> -.. [#]
> -   The Debian base system already provides an editor and a pager
> -   program.
> -

What should packages do if an editor is configured and the "editor"
command is not available?

That's an existing issue but I had never thought about it before.  It
would be nice if policy could say something about it.

Thanks,
Jonathan

Bug#810381: debian-policy: Update wording of 5.6.26 VCS-* fields to reflect the need for security

[Jonathan Nieder]

Russ Allbery wrote:
> Sean Whitton  writes:
>> On Wed, Aug 23 2017, Russ Allbery wrote:

>>> --- a/policy/ch-controlfields.rst
>>> +++ b/policy/ch-controlfields.rst
>>> @@ -962,6 +962,10 @@ repository where the Debian source package is 
>>> developed.
>>> 
>>>  More than one different VCS may be specified for the same package.
>>> 
>>> +For both fields, any URLs given should use a scheme that provides
>>> +confidentiality (``https``, for example, rather than ``http`` or ``git``)
>>> +if the VCS repository supports it.
>>> +
>>>  .. _s-f-Package-List:
>>> 
>>>  ``Package-List``
[...]
> Maybe I should just say:
>
> a scheme that provides confidentiality and integrity protection

Seconded.

> I think I was over-thinking it.
>
> (That said, my understanding is that you don't get any meaningful
> integrity protection for Git from using https over http.)

As discussed elsewhere in this thread, it depends on how much you
trust (a) ca-certificates, versus (b) DNS.

The ideal is to use signed tags and check them.  (Or even better, to
work with git upstream to get push certs distributed properly and
check those.)

It would be nice to get something like chromium's certificate pinning
into curl, but that's a separate topic.

Thanks,
Jonathan

Bug#810381: debian-policy: Update wording of 5.6.26 VCS-* fields to reflect the need for security

[Jonathan Nieder]

Jonathan Nieder wrote:
> Russ Allbery wrote:
>>> On Wed, Aug 23 2017, Russ Allbery wrote:

>>>> --- a/policy/ch-controlfields.rst
>>>> +++ b/policy/ch-controlfields.rst
>>>> @@ -962,6 +962,10 @@ repository where the Debian source package is 
>>>> developed.
>>>> 
>>>>  More than one different VCS may be specified for the same package.
>>>> 
>>>> +For both fields, any URLs given should use a scheme that provides
>>>> +confidentiality (``https``, for example, rather than ``http`` or ``git``)
>>>> +if the VCS repository supports it.
>>>> +
>>>>  .. _s-f-Package-List:
[...]
>> Maybe I should just say:
>>
>> a scheme that provides confidentiality and integrity protection
>
> Seconded.
>
>> I think I was over-thinking it.
>>
>> (That said, my understanding is that you don't get any meaningful
>> integrity protection for Git from using https over http.)
>
> As discussed elsewhere in this thread, it depends on how much you
> trust (a) ca-certificates, versus (b) DNS.

Correction: even if you trust DNS, you also have to trust IP
infrastructure to ensure your traffic goes to the intended destination
without a MITM modifying it.  That means that even with trustworthy
DNS (e.g. using dnssec), if your ISP is compromised then you have
neither meaningful confidentiality protection nor meaningful integrity
protection over http, beyond what your version control system provides
at the application level.

A good VPN can improve on that, depending on the destination of your
traffic.  But given all the above, I have to say, https really does
seem like a meaningful improvement.

All that said, the other points still apply:

> The ideal is to use signed tags and check them.  (Or even better, to
> work with git upstream to get push certs distributed properly and
> check those.)

These two approaches can protect integrity but do not help with
confidentiality.

> It would be nice to get something like chromium's certificate pinning
> into curl, but that's a separate topic.

Something like this (or a revamping of ca-certificates) is needed for
confidentiality in the presence of a MITM.

And I agree with you that policy doesn't need to get into these details.

Thanks,
Jonathan

Bug#810381: debian-policy: Update wording of 5.6.26 VCS-* fields to reflect the need for security

[Jonathan Nieder]

Russ Allbery wrote:
> Jonathan Nieder  writes:
>> Russ Allbery wrote:

>>> (That said, my understanding is that you don't get any meaningful
>>> integrity protection for Git from using https over http.)
>>
>> As discussed elsewhere in this thread, it depends on how much you
>> trust (a) ca-certificates, versus (b) DNS.
>
> FWIW, we're talking about integrity protection at different levels here,
> which has made this a bit confusing.  You're talking about authentication
> of the remote server so that you don't get valid commits (in the sense
> that they fit into the Git hash tree) that aren't present in the real
> remote server.  I was talking about integrity protection at the wire
> protocol level (detection of bit flips in transit, that sort of thing),
> which Git will generally do for you regardless of transport by checking
> the hashes of objects, although I'm not sure if it does a full integrity
> check on all remote packs.

I replied privately in more detail (since this is mostly off-topic for
policy), but it's probably useful to clarify a few things publicly,
too.

Indeed, you're right that Git's application-level protocol protects
against cosmic rays and single-bit flips for all objects transfered.
In protocols like git:// and the CGI-based http:// support, this is
guaranteed by the way the protocol works.  If there are any holes in
this protection (e.g. the support for non-dynamic protocols like
ftp:// and static http:// used to have such a bug) then we consider
that a serious bug and would want to know about it so it can be fixed.
Feel free to contact me at g...@packages.debian.org for more details.

By integrity I was referring to something different: protection
against *malicious* manipulation of the response, by a MITM or other
hostile actor.  Git does not guarantee this unless one of the
following holds:

 A. You have learned the name of the commit or tag you are interested
in in a reliable way out-of-band.  That is, if you check out the
revision to be built by SHA-1 instead of by ref name, then Git
intends to guarantee that what you check out is reliably
determined by that SHA-1.

 B. You use signed tags or push certs to verify that you are checking
out what you intend.  E.g. you can do this by using "git tag -v"
to verify that the code you are checking out was (1) signed by
someone you trust and (2) actually refers to the version you want.
Make sure to pay attention to the output to avoid "replay" attacks
(i.e. trying to pass off an old vulnerable tagged version of a
package for a modern fixed version).  Or

 C. You have transport-level integrity protection, e.g. by using a
protocol like https:// or ssh:// with proper PKI.

If people are expecting Git to guarantee that the code you fetch is
what you intended to fetch without (A), (B), or (C), then we are doing
users a dangerous misservice.  I am concerned about where that
expectation comes from and want to do what I can to improve
documentation to avoid that.  Feel free to contact me at
g...@packages.debian.org to help.

> Protocol-level integrity protection doesn't help if you negotiate that
> protocol with the wrong peer, obviously, and preventing that is rather
> outside the scope of the text we're fiddling with here.

I disagree: one of the main goals of HTTPS and the basis for its
support for confidentiality and integrity is avoiding communicating
with the wrong peer.

> But this is all picking nits -- HTTPS provides both confidentiality and
> integrity protection as wire protocol features, so we can just say that
> the protocol should provide those things, regardless of the somewhat
> pedantic point about whether that integrity protection is meaningful for
> Git.

Agreed.

Thanks,
Jonathan

Bug#810381: debian-policy: Update wording of 5.6.26 VCS-* fields to reflect the need for security

[Jonathan Nieder]

Russ Allbery wrote:
> Jonathan Nieder  writes:

>>  C. You have transport-level integrity protection, e.g. by using a
>> protocol like https:// or ssh:// with proper PKI.
>
> I think it's worth being honest with ourselves here that the proper PKI
> part is not really happening with the Vcs-Git field (or Vcs-Browser for
> that matter) in normal usage in the context of Debian packages and random
> remote hosts.
>
> The bar to the attacker is not zero when https with normal public CAs is
> in use, but it's not very high.

There's no point in continuing to discuss this here.  I'll respond
privately in case you want to pursue it.

> I'm fine with including integrity protection in the protocol description
> anyway, but hopefully no one will think that it implies that https is
> providing strong authentication of the Git server here.  There's non-zero
> authentication, but it's pretty weak.

Without authentication, you don't have confidentiality either.  That's
how this comes up in the policy language: I don't understand why https
would be better or worse at providing confidentiality versus integrity.

One kind of authentication is that HTTPS protocol gives you some
assurance that the peer who first responded to is the same as the peer
for the rest of the connection.  That's enough to deter an unreliable
MITM or a passive MITM.

Jonathan

Bug#877697: ebian-policy: discourage using all 4 digits numbers in Standards-Version

[Jonathan Nieder]

Hi,

Mattia Rizzolo wrote:

> Policy § 5.6.11, after describing the meaning of the digits in the
> policy version, reads:
>
> | Thus only the first three components of the policy version are
> | significant in the Standards-Version control field, and so either
> | these three components or all four components may be specified. [5]
>
> Now, I've only got the impressions that packages should avoid using the
> 4th digit in their Standards-Version field, as that number has no
> meaning when it comes to normative stuff.  I've seen on IRC/MLs all kind
> of comments saying that the 4th digit should be avoided

I have been including the 4th component in packages I maintain.  I
don't know if that's a vote for or against this proposal.

I include it because it makes it unambiguous which version of policy
the team referred to when preparing the package.  Micro policy
releases are not supposed to change the normative stuff but sometimes
they clarify the text of normative sections and that context can be
useful for understanding whether a later clarification was taken into
account in the packaging.

My feeling is that this is fine and that those comments on IRC/MLs are
misguided.  But I could easily be persuaded otherwise.

Thanks and hope that helps,
Jonathan

Bug#878905: debian-policy: Document installability recommendations for dependency alternatives

[Jonathan Nieder]

Hi,

Julian Andres Klode wrote:

> APT's solver is greedy and sometimes has a hard time to recover from paths 
> that
> don't work out in the end. We see this with opencv failing to build on 
> !linux-any
> because:
>
> (1) dconf-service depends default-dbus-session-bus | dbus-session-bus
> (2) default-dbus-session-bus is provided by an Architecture: all package, but
> depends on systemd
>
> APT refuses to install that.
>
> I think it makes sense to amend section 7.1 with the following information:

I agree with this goal.

> Packages on the left hand side of a pipe symbol should either be 
> installable
> or should not exist in the given situation (for example, because it is 
> linux-only
> and the package only exists on non-Linux platform).
>
> This would help reduce hard to solve situations for greedy algorithms.

I'm wondering how a packager would go about fulfilling this recommendation.
Should they audit their dependencies (and dependencies' dependencies, etc) for
installability?  Is there a reliable process they can follow for this?

This is made especially difficult because since policy 4.0.1.0 we are not able
to rely on 'priority: optional' packages being installable any more.

Without such advice, I don't think this makes sense to add as a normative change
to policy (or in other words a policy "should").  An informative note would
still be useful, though.

Thanks,
Jonathan

Bug#880992: debian-policy should not recommend running editor using absolute path

[Jonathan Nieder]

Package: debian-policy
Version: 4.1.0.0

Policy 11.4 sayeth:

11.4. Editors and pagers

Some programs have the ability to launch an editor or pager
program to edit or display a text document. Since there are
lots of different editors and pagers available in the Debian
distribution, the system administrator and each user should
have the possibility to choose their preferred editor and pager.

In addition, every program should choose a good default
editor/pager if none is selected by the user or system
administrator.

Thus, every program that launches an editor or pager must use
the EDITOR or PAGER environment variable to determine the
editor or pager the user wishes to use. If these variables are
not set, the programs /usr/bin/editor and /usr/bin/pager
should be used, respectively.

If read strictly, this says that I must use "/usr/bin/editor" instead
of invoking "editor" from the $PATH.  (I'm not sure I agree with that
interpretation, but it came up in https://bugs.debian.org/682347.)
Running "editor" from the $PATH instead of using that full path should
be perfectly acceptable and IMHO is a better behavior, since it allows
the user to put a custom editor in /usr/local/bin or $HOME/bin.

Could this say something like

not set, the commands "editor" and "pager" should be used,
respectively. These commands can be invoked explicitly (e.g.
as /usr/bin/editor), or through a $PATH search (e.g. as
editor).

?

Bug#880992: debian-policy should not recommend running editor using absolute path

[Jonathan Nieder]

Hi,

Sean Whitton wrote:
> On Mon, Nov 06 2017, Jonathan Nieder wrote:

>>  Thus, every program that launches an editor or pager must use
>>  the EDITOR or PAGER environment variable to determine the editor
>>  or pager the user wishes to use. If these variables are not set,
>>  the programs /usr/bin/editor and /usr/bin/pager should be used,
>>  respectively.
>>
>> If read strictly, this says that I must use "/usr/bin/editor" instead
>> of invoking "editor" from the $PATH.  (I'm not sure I agree with that
>> interpretation, but it came up in https://bugs.debian.org/682347.)
>> Running "editor" from the $PATH instead of using that full path should
>> be perfectly acceptable and IMHO is a better behavior, since it allows
>> the user to put a custom editor in /usr/local/bin or $HOME/bin.
>
> ISTM that the intention is for the user to set EDITOR and PAGER to
> select an editor or pager, rather than putting things called 'editor'
> and 'pager' into PATH.

I understand and agree, but that doesn't mean that packages should
invoke editor using an absolute path.

Policy describes package behavior, not user behavior.

Further, a sysadmin on a shared machine doesn't have a way to set
EDITOR for all users, but they can install an editor command to
/usr/local/bin/.  I've seen sysadmins at a university do something
similar for e.g. a custom build of gcc.  It would be more robust for
the sysadmin to use alternatives instead, but I'm just saying it's
more polite for a package to respect what the user was trying to do.

>This seems sensible because 'editor' and 'pager'
> are fairly generic terms and a user might have things in ~/bin/editor or
> ~/bin/pager that don't edit or page, respectively.

Really?  That would be a reason for the 'editor' and 'pager' commands
to be named something else.  But on the contrary, I find 'editor' and
'pager' to be pretty clear names for what they do.

Is there additional information or context I can provide to change
your mind?  Note that the change I am proposing is to allow packages
to invoke 'editor' from $PATH, not to require them to do so.  There
are existing packages (e.g., Git) that already do this.  This is
similar to upstream packages invoking "less" or "more" from the $PATH
instead of relying on it to be at a particular path.

Jonathan

Bug#683495: Mandating use of /usr/bin/perl in Policy

[Jonathan Nieder]

Bill Allombert wrote:
> On Mon, Nov 27, 2017 at 09:10:12PM +0100, Bill Allombert wrote:
>> On Mon, Nov 27, 2017 at 11:34:15AM -0600, Gunnar Wolf wrote:
>>> Sean Whitton dijo [Sat, Oct 14, 2017 at 11:49:59AM -0700]:

 I am seeking seconds for the following patch to close this bug, which I
 think is uncontroversial at this point.

> @@ -185,7 +185,7 @@ All command scripts, including the package maintainer 
> scripts inside the
>  package and used by ``dpkg``, should have a ``#!`` line naming the shell
>  to be used to interpret them.
>
> -In the case of Perl scripts this should be ``#!/usr/bin/perl``.
> +In the case of Perl scripts this must be ``#!/usr/bin/perl``.
>
>  When scripts are installed into a directory in the system PATH, the
>  script name should not include an extension such as ``.sh`` or ``.pl``
>>>
>>> Seconded.
>>
>> Before we make it a must, is there a lintian test for it ?
>> How may packages need to be fixed ?
>
> Given Russ answer about the lintian test and result, I second this
> proposal.

Seconded as well. Thanks!

Jonathan

Bug#459427: changelog vs. NEWS handling

[Jonathan Nieder]

Hi,

gregor herrmann wrote:

> From the Perl world, looking at roughly ~3400 packages I have locally
> cloned:
>
> 28 have a NEWS file (most of them with a Gnome/GTK background), 1
> News, 1 news.
>
> 3368 have a Changes, CHANGES, Changelog, ChangeLog, (and some other
> variations like Change{s,Log}.{pod,ini,1,txt}); and those files are the
> manually created user-facing summaries of relevant changes of the
> release (in almost all cases).
>
> For 10 packages we have `dh_installchangelogs NEWS' in debian/rules.
>
>
> I'm all for installing NEWS if it's a summary in the GNU style; but
> assuming that ChangeLog etc. are detailed/auto-generated/boring
> doesn't reflect reality in the Perl universe.

Yes.

Some more questions from a policy pov:

 1. What to do with packages that make multiple per-release release
note files?  Should the packager concatenate them or is shipping
them as multiple files ok?  (E.g. see /usr/share/doc/git/RelNotes.)

 2. What about packages that prune old release notes from their source
tarball?  (E.g. Samba's WHATSNEW.TXT doesn't go back very far,
sometimes not even as far as the previous stable Debian release.)

Should packagers copy back in such archived release notes to make
the changelog usable to users?

 3. Any advice for packagers to make complying with the GPL section 5+6
straightforward?

  a) The work must carry prominent notices stating that you modified
  it, and giving a relevant date.

What about when Debian's upstream is downstream from someone else?

Thanks,
Jonathan

Bug#459427: changelog vs. NEWS handling

[Jonathan Nieder]

Josh Triplett wrote:
> On Fri, 1 Dec 2017 00:04:20 +0100 Bill Allombert  wrote:

>> The fact that some upstream do not bother to ship useful changelog does
>> not mean that all changelog are useless, and by removing them we
>> discourage upstream of producing useful changelog.
>
> I sincerely hope so.  Convincing upstreams to "git rm ChangeLog" becomes
> much easier the more widespread existing practice we can point to.
> Having a ChangeLog file in version control is actively detrimental.

I agree with you about GNU-style changelogs.  But I don't think I've
seen those much outside of GNU packages.

How do you feel about generated changelogs in release tarballs that
are generated by tools like "git log"?

> I would go so far as to say that I hope we one day stop shipping
> a non-generated debian/changelog in source packages, because it incurs
> all the same pain.

I've been trying to make debian/changelog in packages I work on
user-focused, and no one has complained yet.

I also use NEWS.Debian for notes about incompatibilities that will
affect sysadmins upgrading.

Thanks,
Jonathan

Bug#614807: debian-policy: Please document autobuilder-imposed build-dependency alternative restrictions

[Jonathan Nieder]

Hi,

Sean Whitton wrote:
> On Thu, Nov 30 2017, Simon McVittie wrote:

>> Other than that, seconded. I'm not sure whether this is necessarily
>> how the autobuilders *should* work, but there's value in documenting
>> how the autobuilders *do* work.
>
> Thank you for reviewing this bug.
>
> Since Sean's patch doesn't require anything of package maintainers, it's
> what we call "informative", and we don't need formal seconds.  So I'm
> going to go ahead and apply the patch.

Thanks.  As a followup, I'm a little confused at what I think is a
wording issue:

> +To avoid
> +   inconsistency between repeated builds of a package, the
> +   autobuilders will default to selecting the first alternative, after
> +   reducing any architecture-specific restrictions for the build
> +   architecture in question.  While this may limit the usefulness of
> +   alternatives in a single release, they can still be used to provide
> +   flexibility in building the same package across multiple
> +   distributions or releases, where a particular dependency is met by
> +   differently named packages.

This means if I write

Build-Depends: a | b

then it will always use 'a', regardless of the release, right?

What is the comment about providing flexibility talking about here?
Is it saying that I can use 'a | b' to provide flexibility for people
building outside an autobuilder environment?

To help backporters, I have used this functionality before and
backporters have uploaded the package as-is to a backports dist that
didn't include 'a'.  The package built against 'b'.  Was this an
autobuilder bug?

Thanks,
Jonathan

Bug#884223: debian-policy: please add AGPL-3.0 to common licenses

[Jonathan Nieder]

Hi,

Markus Koschany wrote:

> as discussed on debian-devel [1] I would like to request that more DFSG
> licenses are added to /usr/share/common-licenses and that package
> maintainers are allowed to reference them.
>
> License: AGPL-3.0
> Source: https://www.gnu.org/licenses/agpl-3.0.de.html
> Example packages:
> https://wiki.debian.org/DFSGLicenses#GNU_AFFERO_GENERAL_PUBLIC_LICENSE_.28AGPL-3.29

What commonly installed packages use this license?  Is ghostscript the
only one, or are there others?

I'm neutral on this change.  ghostscript is installed on most
installations and uses this license and unfortunately pieces of it get
incorporated into other packages like poppler-data.  If it weren't for
ghostscript then I would be against this change.

(src/utils/qpaeq in pulseaudio is about to become a non-example, since
its licensing was simplified to LGPL upstream.)

Thanks and hope that helps,
Jonathan

Bug#884225: debian-policy: please add CC-BY-4.0 to common licenses

[Jonathan Nieder]

Markus Koschany wrote:

> as discussed on debian-devel [1] I would like to request that more DFSG
> licenses are added to /usr/share/common-licenses and that package
> maintainers are allowed to reference them.
>
> License: CC-BY-4.0
> Source: https://creativecommons.org/licenses/by/4.0/
> Example packages:
> https://wiki.debian.org/DFSGLicenses#Creative_Commons_Attribution_unported_.28CC-BY.29_v4.0

Seconded (for CC-BY-SA 4.0 unported, not other Creative Commons
licenses).

Thanks,
Jonathan

> [1] https://lists.debian.org/debian-devel/2017/12/msg00209.html

Bug#884224: ebian-policy: please add CC-BY-3.0 to common licenses

[Jonathan Nieder]

Hi,

Markus Koschany wrote:

> as discussed on debian-devel [1] I would like to request that more DFSG
> licenses are added to /usr/share/common-licenses and that package
> maintainers are allowed to reference them.
>
> License: CC-BY-3.0
> Source: https://creativecommons.org/licenses/by/3.0/
> Example packages:
> https://wiki.debian.org/DFSGLicenses#Creative_Commons_Attribution_unported_.28CC-BY.29_v3.0

Seconded (for CC-SA-3.0 unported).  Seconded only for that license; I
don't mean this to imply that we have consensus to include the texts
of all Creative Commons licenses in base-files!

Thanks,
Jonathan

Bug#884226: debian-policy: please add EPL-1.0 to common licenses

[Jonathan Nieder]

Markus Koschany wrote:

> as discussed on debian-devel [1] I would like to request that more DFSG
> licenses are added to /usr/share/common-licenses and that package
> maintainers are allowed to reference them.
>
> License: EPL-1.0
> Source: https://www.eclipse.org/legal/epl-v10.html
> Example packages:
> https://wiki.debian.org/DFSGLicenses#Eclipse_Public_License_-_1.0

I'm ambivalent on this one.  No strong objection but it seems likely
that small installations could benefit from not having to have this
license text.

I'm wondering if we should split some common licenses out of
base-files to avoid this kind of dilemma.  E.g. if there were some
base-files-eclipse package that provided the EPL-1.0 and we allowed
packages to depend on base-files-eclipse to avoid having to ship the
EPL in their own copyright file, then this dilemma wouldn't exist.
The hypothetical base-files-eclipse package might need to be marked in
some appropriate way to simplify following the spirit of licenses
(just like people know to treat base-files specially and distribute
the license texts from it alongside Debian source packages they
distribute).

Thanks,
Jonathan

> [1] https://lists.debian.org/debian-devel/2017/12/msg00209.html

Bug#884227: debian-policy: please add zlib to common licenses

[Jonathan Nieder]

Markus Koschany wrote:

> License: zlib
> Source: https://opensource.org/licenses/Zlib
> Example packages:
> https://wiki.debian.org/DFSGLicenses#The_zlib.2Flibpng_License_.28Zlib.29

Hm.  The license says

  3. This notice may not be removed or altered from any source distribution.

And part of 'This notice' is a copyright line that varies from package
to package.  Since the license text is very short, it seems simplest
for packages to keep reproducing the license text --- it's not too
painful disk space-wise and it is much clearer license-wise.

So I don't believe it belongs in common-licenses.

Thanks,
Jonathan

> [1] https://lists.debian.org/debian-devel/2017/12/msg00209.html

Bug#884228: debian-policy: please add OFL-1.1 to common licenses

[Jonathan Nieder]

Markus Koschany wrote:

> as discussed on debian-devel [1] I would like to request that more DFSG
> licenses are added to /usr/share/common-licenses and that package
> maintainers are allowed to reference them.
>
> License: OFL-1.1
> Source: https://opensource.org/licenses/OFL-1.1
> Example packages:
> https://wiki.debian.org/DFSGLicenses#The_SIL_Open_Font_License

Seconded.

Thanks,
Jonathan

> [1] https://lists.debian.org/debian-devel/2017/12/msg00209.html

Bug#884223: debian-policy: please add AGPL-3.0 to common licenses

[Jonathan Nieder]

Hi,

Markus Koschany wrote:
> Am 13.12.2017 um 19:10 schrieb Jonathan Nieder:
>> Markus Koschany wrote:

>>> License: AGPL-3.0
>>> Source: https://www.gnu.org/licenses/agpl-3.0.de.html
>>> Example packages:
>>> https://wiki.debian.org/DFSGLicenses#GNU_AFFERO_GENERAL_PUBLIC_LICENSE_.28AGPL-3.29
>>
>> What commonly installed packages use this license?  Is ghostscript the
>> only one, or are there others?
>
> Actually my idea was not to distinguish between "commonly installed"
> packages and simply "used in packages" anymore. Maintainers will roughly
> save the same amount of time by not copying this license.

This seems odd to me.  Wouldn't copying upstream's LICENSE file
verbatim be the action that involves the least amount of time?  I have
always assumed common-licenses is about disk space and transfer time
savings, not maintainer time savings.

> Apart from my example packages you can find this license also in the
> following packages: Just go to codesearch.debian.net and use
>
>  AGPL path:debian/copyright
>
> as your search query. Notable packages are pulseaudio, debian-goodies,
> gnutls28, pelican, and many more. I expect that more network or web
> applications will use this license in the future.

Thanks.  The example in pulseaudio is the bug fixed upstream that I
mentioned before (src/utils/qpaeq had a different license from the
rest of the package; they've fixed it now).

I remain neutral on this change.  I'm not against it, but not
enthusiastic about it, and look forward to hearing others' thoughts on
it before seconding.

Sincerely,
Jonathan

Bug#884226: debian-policy: please add EPL-1.0 to common licenses

[Jonathan Nieder]

Hi,

Markus Koschany wrote:

> I would like to argue that disk space is no longer an issue in 2017 and
> people with special needs (embedded systems) will most likely remove
> /usr/share/common-licenses anyway.

I agree: space on installation media and network transfer time are more
important than disk space these days.


>Thus the more DFSG-licenses we
> install into /usr/share/common-licenses the more time can be saved for
> more important issues than quoting licenses.

I'm confused.  Can you explain your workflow a little more?

I wouldn't expect using upstream's LICENSE file to take significantly
more time than replacing it with a pointer to common-licenses.  I'd
actually expect it to take more time.

If all we care about is maintainer time spent, then we should
eliminate common-licenses.

Puzzled,
Jonathan

Bug#884226: debian-policy: please add EPL-1.0 to common licenses

[Jonathan Nieder]

Hi again,

Markus Koschany wrote:

> Let me try to explain it this way: Take src:ufoai-data or src:netbeans
> for example. Both packages ship approximately a dozen different
> licenses. I can't simply copy&paste the upstream license because I have
> to format it to make it copyright format 1.0 compliant.

Aha, that explains it.

Policy does not require using copyright format 1.0, but many packagers
choose to use it.  It sounds like we need better tools to help them.

But with a goal in mind of saving maintainer time, shouldn't we
discourage using copyright format 1.0 when the upstream LICENSE file
is clear?  (I personally think the maintainer time involved is very
little relative to the work of either manually or using tools
verifying that the license is correctly documented --- e.g. comparing
source file headers to the LICENSE file.  I'm just going along with
the saving time argument.  I suspect the best way forward will be to
improve tools.)

Thanks,
Jonathan

Bug#883950: debian-policy: allow specifying common licenses with only the identifier

[Jonathan Nieder]

Hi Markus,

Markus Koschany wrote:
> Am 16.12.2017 um 15:55 schrieb Sean Whitton:
>> On Wed, Dec 13 2017, Markus Koschany wrote:

>>> If the Policy editors cannot make a decision with regards to
>>> debian/copyright then we should ask the DPL to seek legal advice and
>>> when necessary start a GR for reasons of legitimacy.
>>
>> If we think this issue is important enough to spend money on that.  I am
>> not convinced it is.
>
> Then we need a GR. Simply claiming that something violates the law
> without proof cannot be the right way for a large project like Debian.
> This is a very important topic because writing debian/copyright is not
> optional in Debian. I simply believe that most people appreciate doing
> something meaningful in their free time.

You are of course free to initiate a GR at any time.

I have no opinion about this particular proposal (allowing specifying
common licenses with only the identifier).  But I am worried at how
black and white you are describing the world to be.

Debian has long had a practice of being extra careful to respect the
wishes of free software authors as expressed in the licenses they
choose.  This goes beyond the minimum legal requirements of license
compliance.  It is not because the project is afraid of being sued but
because at least some in the project consider it to be the right thing
to do.

Here Sean pointed out that just a license name with too little
accompanying text does not appear to be particularly clear to end
users.  That means end users may not know what their rights are, so it
seems worth thinking about.  Fortunately DEP-5 copyright files contain

 Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

so perhaps some information in the copyright-format would be good
enough to help those end users.  Perhaps not.  But I am puzzled that
you seem to think there is only one possible right answer and that it
should be obvious to everybody.

The way you describe the experience of writing a debian/copyright file
is foreign to my own experience.  It sounds like making the process of
generating /usr/share/doc/{package}/copyright using *automated tools*
in a smoother way will be a good avenue for addressing the developer
experience issues you are mentioning.  Then you'd be in a better
position to come up with what the appropriate content of that file
should be to serve end users.

Thanks and hope that helps,
Jonathan

Bug#688251: Built-Using description too aggressive

[Jonathan Nieder]

Hi,

Sean Whitton wrote:

> --- a/policy/ch-relationships.rst
> +++ b/policy/ch-relationships.rst @@ -598,17 +598,26 @@ earlier for
> binary packages) in order to invoke the targets in
>  Additional source packages used to build the binary - ``Built-Using``
>  -
> 
> -Some binary packages incorporate parts of other packages when built but
> -do not have to depend on those packages. Examples include linking with
> -static libraries or incorporating source code from another package
> -during the build. In this case, the source packages of those other
> -packages are a required part of the complete source (the binary package
> -is not reproducible without them).
> +Some binary packages incorporate parts of other packages when built
> +but do not have to depend on those packages. Examples include linking
> +with static libraries or incorporating source code from another
> +package during the build. In this case, the source packages of those
> +other packages are part of the complete source (the binary package is
> +not reproducible without them).

Is this part just a line-wrapping change?  If so, feel free to check it
in directly to make the normative diff easier to review.

> -A ``Built-Using`` field must list the corresponding source package for
> -any such binary package incorporated during the build, [#]_ including
> -an "exactly equal" ("=") version relation on the version that was used
> -to build that binary package.  [#]_
> +When the license of either the incorporated parts or the incorporating
> +binary package requires that the full source code of the incorporating
> +binary package be made available, the ``Built-Using`` field must list
> +the corresponding source package for any affected binary package
> +incorporated during the build, [#]_ including an "exactly equal" ("=")
> +version relation on the version that was used to build that version of
> +the incorporating binary package.  [#]_
> +
> +This causes the Debian archive to retain the versions of the source
> +packages that were actually incorporated.  In particular, if the
> +versions of the incorporated parts are updated but the incorporating
> +binary package is not rebuilt, the older versions of the incorporated
> +parts will remain in the archive in order to satisfy the license.

Sounds good.

[...]
> @@ -625,6 +634,11 @@ field in its control file:
> 
>  Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1)
> 
> +This field should not be used for purposes other than satisfying
> +license or DFSG requirements to provide full source code.  In
> +particular, it should not be used to enable finding packages that
> +should be rebuilt against newer versions of their build dependencies.

This feels overly aggressive to me: if the field is already set, why
wouldn't I use it to find packages to rebuild?  I think the intent is
something closer to "In particular, it should not be added solely to
enable finding packages that should be rebuilt [...]".

That said, seconded.

Thanks,
Jonathan

Bug#885219: /lib64 provision added in 9.1.1 prohibits multilib libc

[Jonathan Nieder]

Russ Allbery wrote:

> Allow libc to install files in /lib64
>
> diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst
> index 7d9e20a..d7c4956 100644
> --- a/policy/ch-opersys.rst
> +++ b/policy/ch-opersys.rst
> @@ -35,7 +35,8 @@ Debian Policy. The following exceptions to the FHS apply:
>  character.
> 
>  3.  The requirement for amd64 to use ``/lib64`` for 64 bit binaries is
> -removed.  Only the dynamic linker is allowed to use this directory.
> +removed.  Only the dynamic linker and libc are allowed to use this
> +directory.
> 
>  4.  The requirement for object files, internal binaries, and libraries,
>  including ``libc.so.*``, to be located directly under ``/lib{,32}``

Seconded.

Thank you,
Jonathan

Bug#884228: debian-policy: please add OFL-1.1 to common licenses

[Jonathan Nieder]

Markus Koschany wrote:
> Am 28.12.2017 um 11:21 schrieb Bill Allombert:
>> On Wed, Dec 27, 2017 at 01:56:44PM -0800, Russ Allbery wrote:
>>> Jonathan Nieder  writes:

>>>> Seconded.
>>>
>>> license-count says this makes sense:
>>>
>>> SIL OFL 1.0  12
>>> SIL OFL 1.1 159
>>>
>>> via the historic criteria of more usage than the least popular license
>>> already in common-licenses (GFDL 1.3 at 138 packages).
[...]
>> The usual threshold for inclusion was much higher than 138.
[...]
> We really should move away from making a distinction between popular and
> non-popular DFSG licenses. Nowadays nobody in the project can tell
> within seconds how many DFSG-free licenses there are. Under my original
> proposal we would add _all_ licenses which were accepted by the FTP team
> to /usr/share/common-licenses.

I am confident that we lack consensus for that original proposal.

I have some sympathy for moving to a different threshold or a
different criterion for inclusion in common-licenses.  But let me just
say now to avoid wasted time: I am not going to be supportive of
turning base-files into a compendium of all DFSG licenses.  There are
multiple reasons that I don't think that's in users' best interests.
I've already discussed some of them and haven't heard any convincing
new points in response.

> Also the criterion of popularity does not take into account that some
> licenses are more frequently used in specific fields of endeavor. If you
> don't maintain a lot of -data or documentation packages with fonts,
> images or other media files, this is probably not an issue for you. But
> the current state surely is annoying for contributors who are interested
> to develop parts of Debian where the OFL or CC licenses are very popular
> and common.

As I've already said multiple times, if you are using copyright-format
1.0 to maintain multiple packages and it is getting in your way,
please please please, fix your workflow and improve documentation so
others can benefit from the same workflow changes.  Work with upstream
to ensure they have high quality license documentation that you can
use as-is (or that you can use after some mechanical transformations
--- e.g. I've heard of R module packagers having some success with
that approach).  Changing the list of licenses in base-files does not
change this at all.

All that said, I still support including the SIL OFL 1.1 in
common-licenses.  I also agree with you that number of packages is an
imperfect criterion --- the OFL 1.1 is not only used by a large number
of packages but many of those packages are popular, so the resource
savings (archive space in partial mirrors, bandwidth, CD size, etc) is
greater than it might seem at first glance.

Thanks,
Jonathan

Bug#884228: debian-policy: please add OFL-1.1 to common licenses

[Jonathan Nieder]

Hi,

Markus Koschany wrote:

>  I still have to quote license texts verbatim. The only
> "advantage" of the old format is that I can format d/copyright more
> freely but the same information must be present anyway. It is simply not
> feasible to educate all upstreams in existence to write a Debian-like
> copyright file. They rightly say that it is not their problem how
> downstreams process and treat their copyright information.

This may be the source of my confusion.  I am used to upstreams being
cooperative when I ask them for a clear LICENSE file, especially when I
provide them with a patch to do so.

Some licenses even require that.  Upstream has to follow the license,
too, when they incorporate code from third parties.  Even in a
situation where they wrote all the code themselves, making license
compliance easy for downstream users helps adoption of their code.

In other words, I have almost never experienced the kind of resistance
you are talking about.

Even a package that adopts copyright-format 1.0 does not need to put
per-file license information in debian/copyright.  It is perfectly
okay to have a single 'Files: *' paragraph with the project's license.
Some maintainers prefer to maintain per-file license information since
they think it makes their lives easier.

Thanks,
Jonathan

Bug#884228: debian-policy: please add OFL-1.1 to common licenses

[Jonathan Nieder]

Markus Koschany wrote:

> freeorion: [1]
>
> Rather sophisticated game GPL-2 licensed but with various contributions
> / incorporations under different licenses. So I can't just write Files:
> * -> GPL-2. I have to list all licenses with separate paragraphs and
> there is no way to change that without sacrificing accuracy. But
> d/copyright would be a lot more readable if I did not have to quote some
> of those licenses verbatim.

Using 'Files: *' when different files are under different licenses
sacrifices precision, but it doesn't sacrifice accuracy.  You can say

 Files: *
 License: GPL-2 and Permissive-License-1 and Permissive-License-2 and ...

Or you can even write

 Files: *
 License: Freeorion

and clarify what the terms are in the license text.  At least that was
my understanding of the intent behind copyright-format.

Looking at the latest clarifications to copyright-format, I see

 Files: *
 Copyright: 1975-2010 Ulla Upstream
 License: GPL-2+

 In this example, copyright in all files is held by the upstream, and
 that copyright holder grants license under the GPL, version 2 or
 later.

which I fear is ambiguous.  If the copyright field names multiple
copyright holders, do all files have to be copyright by all of them,
or can the copyright to some files be held by some of them and to
others by the other?  The latter is the only tenable way this can work
in practice but the text could use some clarification (in a separate
bug).

> bullet: [2]
>
> C++ library under a permissive license with various contributions
> licensed under different licenses. I became fed up with checking the
> data and examples directories with each upstream release because of the
> various licenses and copyright holders in those directories. Fortunately
> we don't need those for a functioning library but it would have been
> nice for someone who wants to build demos and examples on a local
> system. -> forced trade-off between usefulness, d/copyright and my
> maintenance time. Nothing upstream could help us with.

Can't upstream help by hosting a LICENSE file that you and other
distributors share the work of maintaining?

If they prefer to treat the data and examples directories as
independent components, they can put a LICENSE file in each, so that
all that would be left on the Debian side to do is (1) concatenate
them and (2) remove any directories that don't have a LICENSE file
yet.

> ufoai-maps: [3]
>
> ~5000 files, a lot of CC licensed files. Only manageable because
> upstream provides a copyright file in their own format. I had to write
> my own little parser to make it suitable for d/copyright. Checking this
> all by hand would be a nightmare. Nothing upstream could help us with.
> From their point of view they have provided all legally required
> information.

copyright-format 1.0 is not mandatory.  Why not ship upstream's
copyright file as is?

> netbeans: [4]
>
> ~8 files with dozens of licenses and hundreds of contributors. This
> is only maintainable copyright-wise because I remove lots of files when
> repacking the tarball.

*nod* This is a similar case to bullet.  Upstream is likely not
interested in creating a LICENSE file but they could be interested in
accepting it as a contribution, especially if you set them up with a
licensecheck-like workflow to keep it from bitrotting.

> From my perspective every simplification of d/copyright helps. If you
> think my workflow is to blame here, I'm all ears now how I could be more
> efficient in maintaining just these four packages. ;)

Some of the pain is essential pain due to the way copyright works and
the complexity of conveying authors' wishes.  But other parts are
self-imposed.  I agree with your goal of removing self-imposed pain. :)

Thanks,
Jonathan

Bug#884228: debian-policy: please add OFL-1.1 to common licenses

[Jonathan Nieder]

Jonathan Nieder wrote:
> Markus Koschany wrote:

>> freeorion: [1]
>>
>> Rather sophisticated game GPL-2 licensed but with various contributions
>> / incorporations under different licenses. So I can't just write Files:
>> * -> GPL-2. I have to list all licenses with separate paragraphs
[...]
> Looking at the latest clarifications to copyright-format, I see
>
>  Files: *
>  Copyright: 1975-2010 Ulla Upstream
>  License: GPL-2+
>
>  In this example, copyright in all files is held by the upstream, and
>  that copyright holder grants license under the GPL, version 2 or
>  later.
>
> which I fear is ambiguous.  If the copyright field names multiple
> copyright holders, do all files have to be copyright by all of them,
> or can the copyright to some files be held by some of them and to
> others by the other?

Fortunately [1] says

  Not all copyright notices may apply to every individual file

so a pointer to there might be enough to remove the ambiguity for the
Copyright field.

[2] says

  This field should include all text needed in order to fulfill both
  Debian Policy's requirement for including a copy of the software's
  distribution license (12.5), and any license requirements to include
  warranty disclaimers or other notices with the binary package.

but doesn't speak to what to do when e.g. license requirements or
warranty disclaimers vary between files matching the file pattern.

Thanks,
Jonathan

[1] 
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#copyright-field
[2] 
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#license-field

Bug#892142: debian-policy: update example to use default-mta instead of exim

[Jonathan Nieder]

tags 892142 + patch
quit

Hi,

Paul Wise wrote:

> In Policy 7.1. Syntax of relationship fields, there is an example:
>
>For example, a list of dependencies might appear as:
>
>Package: mutt
>Version: 1.3.17-1
>Depends: libc6 (>= 2.2.1), exim | mail-transport-agent
>
> I would like to suggest that this be updated to replace exim with
> default-mta, since exim is no longer in Debian as it has been replaced
> with exim4 and many years ago we switched to using the default-mta
> virtual package to make it easier to change the default MTA on Debian.
>
> https://www.debian.org/doc/debian-policy/#syntax-of-relationship-fields

Thanks!  This is non-normative, so a policy editor can just make the
change.

How about this patch?  It should be possible to apply by downloading
this message as an mbox and using "git am --scissors mbox-file".

-- >8 --
Subject: Use default-mta in MTA dependency example

Reported-by: Paul Wise 
Closes: #892142
---
 debian/changelog| 5 +
 policy/ch-relationships.rst | 2 +-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index 0ec082f..99f6068 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,5 +1,6 @@
 debian-policy (4.1.4.0) UNRELEASED; urgency=medium
 
+  [ Sean Whitton ]
   * Policy: Drop get-orig-source rules target
 Wording: Helmut Grohne 
 Seconded: Holger Levsen 
@@ -29,6 +30,10 @@ debian-policy (4.1.4.0) UNRELEASED; urgency=medium
   * Fix indentation of description of the clean target (Closes: #889960).
 Thanks Ferenc Wágner for the report.
 
+  [ Jonathan Nieder ]
+  * Use default-mta instead of exim in dependency example (Closes: #892142).
+Thanks to Paul Wise for the report.
+
  -- Sean Whitton   Fri, 29 Dec 2017 18:46:59 +
 
 debian-policy (4.1.3.0) unstable; urgency=medium
diff --git a/policy/ch-relationships.rst b/policy/ch-relationships.rst
index 77cf0e1..1eaa422 100644
--- a/policy/ch-relationships.rst
+++ b/policy/ch-relationships.rst
@@ -45,7 +45,7 @@ For example, a list of dependencies might appear as:
 
 Package: mutt
 Version: 1.3.17-1
-Depends: libc6 (>= 2.2.1), exim | mail-transport-agent
+Depends: libc6 (>= 2.2.1), default-mta | mail-transport-agent
 
 Relationships may be restricted to a certain set of architectures. This
 is indicated in brackets after each individual package name and the
-- 
2.16.2.660.g709887971b

Bug#515856: Debian Policy 4.1.4.0 released

[Jonathan Nieder]

Hi,

Sean Whitton wrote:
> On Wed, Apr 11 2018, Russ Allbery wrote:

>> I'm pretty reluctant to specify this sort of optional target that
>> works differently in every package that uses it back in Policy because
>> it's really not standardized, nor do I think it's possible to
>> standardize.  If we really want to write something down about the
>> target, maybe the Developer's Reference would be a better spot?  There
>> were a whole host of issues with having this in Policy that were
>> resolved by moving it outside the scope of Policy, such as how to
>> document dependencies required for running the get-orig-source target.
>
> The Developer's Reference seems like a more appropriate place for a
> convention that it is not possible to specify precisely.

I'm a bit confused: wasn't it already specified pretty precisely?

I would be in favor of adding the target back, with a description
along the lines of "If you provide a get-orig-source target, it should
satisfy .  If you provide neither a get-orig-source
target nor a debian/watch file and you do not use an archive from
upstream as-is, please include clear instructions in README.source to
allow a human to produce an upstream tarball."

Context: I have run into a few packages that used the +dfsg convention
without documenting what they removed from the tarball and I was not
able to locally update them. :(

Thanks,
Jonathan

Bug#515856: Debian Policy 4.1.4.0 released

[Jonathan Nieder]

Hi,

Sean Whitton wrote:
> On Mon, Jul 02 2018, Jonathan Nieder wrote:

>> I'm a bit confused: wasn't it already specified pretty precisely?
>
> Please take a look through the bug's discussion.  It's explained why the
> wording was not thought to be good enough.

Thanks.  This looks like a classic case of letting the perfect be the
enemy of the good (or perhaps, of not understanding the use case for
which the existing practice was good enough).  Some quotes from the
bug:

| According to codesearch.d.n, get-orig-source is implemented by less than
| 3000 source packages. This is not very low, but neither a high adoption
| rate. It certainly makes using get-orig-source somewhat useless on a
| distribution-scale.

Certainly it's even more useful to have a debian/watch file, but this
doesn't make it clear to me what I'm supposed to do with those 3,000
source packages now.

|  * The requirement that get-orig-source may be invoked from any
|directory is difficult to fulfil and often times not implemented. A

This hasn't been an obstacle to my use.  I can even try multiple
directories.  What's helpful for me is that it works from *somewhere*.

|  * It is not clear whether the most recent upstream version or the
|currently packaged version should be downloaded.

Likewise, either works fine for my use.

|  * It is not clear where required tools should be declared.

As long as the command prints an error about the required tool, I can
install it.

| We're just reducing
| the documented interfaces of packages a bit based on current trends,
| which is useful for newcomers to Debian.

What is a newcomer supposed to do now when they encounter a package
that does not provide an explanation of how to generate the upstream
tarball?

Jonathan

Bug#886258: Clarify whether or not the Standards-Version field must be present, or lower Lintian tag severity

[Jonathan Nieder]

Hi,

Chris Lamb wrote:
> Sean Whitton wrote:

>> Either Policy should mandate this field, or it should not be a Lintian
>> error when it is not present.
>
> Any update on this? It is somewhat tempting to re-assign this to Policy
> alone until there is a resolution there. What say you? :)

https://www.debian.org/doc/debian-policy/#source-package-control-files-debian-control
says 'Standards-Version (recommended)', meaning that specifying it is
recommended but not mandatory.  I think it's okay for lintian to error
out without it just because it's essential information that *lintian*
needs in order to do its job.

What does the lintian lab say about prevalence in the archive?  Is it
widely enough used that we could make it mandatory, make it an
ftpmaster autoreject, etc?

Thanks and hope that helps,
Jonathan

Bug#685746: Seeking seconds for a patch to deal with remaining issues in this old bug

[Jonathan Nieder]

Sean Whitton wrote:

Seeking seconds:
>
> diff --git a/policy/ch-relationships.rst b/policy/ch-relationships.rst
> index 1eaa422..03f5918 100644
> --- a/policy/ch-relationships.rst
> +++ b/policy/ch-relationships.rst
> @@ -228,6 +228,10 @@ The meaning of the five dependency fields is as
> follows:
>  The ``Recommends`` field should list packages that would be found
>  together with this one in all but unusual installations.
>
> +It is not a bug if some things in the package do not work properly
> +because the user has not installed packages listed in
> +``Recommends``.
>

That would mean Recommends is effectively Depends. Is it really what you
intend?

Common practice is for a package to still function ok without Recommends,
for example by printing an appropriate error message when the user invokes
missing functionality.

Jonathan

Bug#685746: Seeking seconds for a patch to deal with remaining issues in this old bug

[Jonathan Nieder]

Sean Whitton wrote:

> On Sun 22 Jul 2018 at 11:12PM -0700, Jonathan Nieder wrote:
>


> > That would mean Recommends is effectively Depends. Is it really what you
> > intend?
>
> I don't follow.
>
> My patch says that /some/ functionality might not work without the
> recommends.
>

It comes down to what "might not work" means.

For example, "might reformat your hard drive" is an example of "might not
work".

This might seem pedantic, but it really isn't: I've seen packagers argue
that they are not responsible for what happens on user systems that do not
install Recommends before.

Jonathan

Bug#904608: Support specifying upstream VCS location in debian/control

[Jonathan Nieder]

Hi,

Sean Whitton wrote:
> On Wed 25 Jul 2018 at 05:14PM +0100, Iain Lane wrote:

>> Some tools, like git-buildpackage, can support merging an upstream's
>> version history into Debian packaging repositories. This enables more
>> rich usage of (D)VCS when packaging - for example `git blame' works
>> properly.
>>
>> Currently there's no canonical place to specify where upstream's VCS is
>> located so people have to set this up manually themselves. If there were
>> such a place, it would be possible for tools like `gbp clone' to
>> configure the VCS to know about the upstream history when checking out a
>> packaging repository.

I like this use case.  Thanks for bringing it up.

> In fact, there is: the Repository field in debian/upstream/metadata.[1]

Neat!

I would have expected to find this information in debian/copyright.  The
Source field there sometimes names an upstream VCS but isn't required to
do so; I'd be in favor of some tightening of the requirements in
copyright-format based on how packages in the archive have been using
the field (for example, encouraging a list of lines each of which has
the same format as Vcs-* fields).

>> The request here is to ask whether this would be suitable for
>> debian/control, along the lines of the Vcs-* fields specified in 5.6.26
>> and the Homepage field in 5.6.23.

My feeling is that it doesn't belong in debian/control.

The debian/control file is the source for control fields that appear
in the binary package, Packages file, and Sources file.  If I
understand correctly, the primary consumers of this field would
already have a copy of the source (via Vcs-Git) so they can get the
information from other files in the debian/ directory; they don't need
to get it from the Sources file.

With that in mind, Sean's suggestion of using debian/upstream/metadata[1]
sounds good to me.  Would it work well for you?

>> If so, I'd be happy to propose wording for policy. I'm not set on any
>> particular name, so please feel free to weigh in on that if you'd like.
>
> Even if we did want to add this to d/control files, we would want to see
> it already used in d/control files in the archive before documenting
> that in Policy.

On this subject more generally, I think there's a bit of a
chicken-and-egg problem.  If we want new fields in the Packages or
Sources file, it does make sense to coordinate a little with potential
consumers, and it's not obvious to me where the right place to start
that is (d...@packages.debian.org? a DEP? something else?).  So I
understand why people ask policy team.

For the future, I'd like to have good advice to offer for this kind of
case, even if that advice is as simple as "ask d...@packages.debian.org"
or "ask ftp-master", say.

Thanks,
Jonathan

> [1]  https://wiki.debian.org/UpstreamMetadata

Bug#459427: Patch seeking seconds on changelog vs. NEWS handling

[Jonathan Nieder]

Hi,

Sean Whitton wrote:
> On Mon 23 Jul 2018 at 01:40PM +0200, gregor herrmann wrote:

>> Let me see if I got this right, and apply it to the typical pkg-perl
>> package:
>>
>> CPAN distributions usually contain no NEWS file, and do contain a
>> Changes/ChangeLog/... file which is "an upstream release notes file"
>> per the above definition (hand-written by the upstream maintainer,
>> targetted at end users). (Numbers in message #65 in this bug report.)
>>
>> Currently we (i.e. typically dh_installchangelogs) install this
>> Changes file as /usr/share/doc/package/changelog.gz. In the future
>> we'd need to install it as /usr/share/doc/package/NEWS.gz; or still
>> as changelog.gz if we can live with the deprecation (will this be
>> allowed "forever"?).
>
> Until we can remove the deprecation without making more than a handful
> of packages buggy.  So, probably not for a long time.

I share gregor's discomfort: I don't think we've thought this through.

Can you summarize the goals for me?  My understanding of the current
status is:

 1. Installing all of upstream's release notes and source-level
changelogs is allowed.  Many people want to install fewer.

 2. Sometimes upstream doesn't provide adequate release notes.

 3. Sometimes upstream provides sensible release notes, but not as part
of the source archive they distribute.

 4. Some licenses require distributing source-level changelogs.

 5. Policy 12.7, perhaps inspired in part by those licenses, describes
where the upstream changelog (without specifying which changelog is
meant) should be installed and requires that it be installed
there.  It also has some requirements about format, compression
level, and so on.

 6. No tools other than lint and humans' muscle memories rely on the
path it specifies.

Am I understanding correctly so far?

Given that background and my understanding of the goals, my proposal
would be

 i.  We come up with which changelogs we want to *require* shipping,
 if any.

 ii. We don't impose any requirement on filename other than that they
 go in /usr/share/doc//.

 iii. We come up with what format requirements we want to impose on
  the changelogs, if any.

And we should take (2), (3), (4), and (6) into account when doing so.
Also, if my assumptions missed some pieces, I'd like to see them
clarified explicitly to avoid working at cross-purposes.

Thanks,
Jonathan

Bug#459427: Patch seeking seconds on changelog vs. NEWS handling

[Jonathan Nieder]

Sean Whitton wrote:
> On Wed 25 Jul 2018 at 07:01PM -0700, Jonathan Nieder wrote:

>> I share gregor's discomfort: I don't think we've thought this through.
>
> I too want Policy to be as correct as possible, but this bug has been
> open for ten years and one thing upon which there is certainly consensus
> is that the current text is not satisfactory.  We should not let the
> perfect be the enemy of the good, at least in this case.

*puzzled* I am not asking for Policy to be more correct.  I'm asking
for it to provide guidance that can help me with my own packages.

I'm providing the data point that for me, the proposed patch to this bug
does not work at all.  It is way too restrictive, and the argument being
presented in favor of it is that I am allowed to ignore it.  This
isn't about the perfect being the enemy of the good.  This is about
wanting Policy to help me at all.

Your response also feels dismissive.  I've tried to be very concrete
in the input I provide here and I am wondering if this is appreciated
at all or if you consider my contributions to be a nuisance.

>> Can you summarize the goals for me?
>
> 1. Stop encouraging the installation of changelogs, which sometimes has
>the effect of causing our package maintainers to request such logs
>from upstream.  This is not a good use of anyone's time.

In that case, why don't we remove the requirement altogether?

That would be a simple change, and it would achieve the goal, if that
is our main goal.

> 2. Explicitly encourage installing release notes and have a sensible
>filename for them.

I don't see a need for policy to do the first of those two things.
Packagers already install release notes when available, without
requiring any nudge from policy.

As for a sensible filename, I don't see this conversation having
developed toward any consensus (unless changelog.gz is that filename).

[...]
>>  4. Some licenses require distributing source-level changelogs.
>
> Could you give me an example of such a license, please?

The GPL contains the following:

  5. Conveying Modified Source Versions.

  You may convey a work based on the Program, or the modifications to
  produce it from the Program, in the form of source code under the terms of
  section 4, provided that you also meet all of these conditions:

a) The work must carry prominent notices stating that you modified
   it, and giving a relevant date.
[...]
  6. Conveying Non-Source Forms.

  You may convey a covered work in object code form under the terms
  of sections 4 and 5, provided that you also [...]

If Debian modifies a package, we comply with this prominent notice
requirement using the Debian changelog.  If the immediate upstream of
Debian modifies a package, then we ought to indicate when the
immediate upstream has modified the code, and the upstream changelog
accomplishes that.

This isn't too unusual.  The Apache license also contains a similar
provision about indicating that files have been modified, for example.

[...]
>>  ii. We don't impose any requirement on filename other than that they
>>  go in /usr/share/doc//.
>
> I disagree.
>
> It is useful to be able to just type `zless
> /usr/share/doc/foo/known-filename` rather than having to look at the
> filenames and guess what they are.

How do you do that on existing packages?  This bug was opened because
there isn't a consistent practice.

>>  iii. We come up with what format requirements we want to impose on
>>   the changelogs, if any.
>
> This is far out of scope for this bug.

If we set the filename and want people to type zless, then we are
imposing a format requirement (gzip).

Hope that helps,
Jonathan

Bug#904248: Add netbase to build-essential

[Jonathan Nieder]

Hi,

Sean Whitton wrote:

> Thank you for the discussion, Ian and Simon.  Here is the beginnings of
> a patch:
>
>> diff --git a/policy/ch-source.rst b/policy/ch-source.rst
>> index 9e7d79c..f27226e 100644
>> --- a/policy/ch-source.rst
>> +++ b/policy/ch-source.rst
>> @@ -40,9 +40,15 @@ example, if building a package requires a certain 
>> compiler, then the
>>  compiler should be specified as a build-time dependency.
>>
>>  It is not necessary to explicitly specify build-time relationships on a
>> -minimal set of packages that are always needed to compile, link and put
>> -in a Debian package a standard "Hello World!" program written in C or
>> -C++. The required packages are called *build-essential*, and an
>> +minimal set of packages that are always needed
>> +
>> +- to compile, link and put in a Debian package a standard "Hello
>> +  World!"  program written in C or C++; and
>> +
>> +- for the package build to resolve the system hostname to a
>> +  fully-qualified domain name using the C standard library. [#]_

Looks okay to me.  As an alternative, we could encourage packages to
add an explicit Build-Depends on netbase if they need this
functionality.

I think in the long run, I would prefer that since it would make the
concept of build-essential easier for new packagers to learn.  Can we
both make it build-essential and recommend that packages include the
Build-Depends (as a policy "should" instead of a "must") to get the
best of both worlds?  That way, we'd have a path to eventually
simplifying back again.

Thanks,
Jonathan

Bug#904248: Add netbase to build-essential

[Jonathan Nieder]

Hi,

Sean Whitton wrote:
> On Wed 25 Jul 2018 at 09:14PM -0700, Jonathan Nieder wrote:

>> Looks okay to me.  As an alternative, we could encourage packages to
>> add an explicit Build-Depends on netbase if they need this
>> functionality.
>>
>> I think in the long run, I would prefer that since it would make the
>> concept of build-essential easier for new packagers to learn.  Can we
>> both make it build-essential and recommend that packages include the
>> Build-Depends (as a policy "should" instead of a "must") to get the
>> best of both worlds?  That way, we'd have a path to eventually
>> simplifying back again.
>
> build-essential is a set of functionality, whereas netbase is a
> particular implementation of some of that functionality.  Coupling a
> requirement in the build-essential set to the current implementation in
> the Debian system would seem to defeat the point of including that
> requirement in the build-essential set.

I don't agree with this logic: if we need a virtual package to
describe network-access-works to abstract away from netbase, that's
very easy to do.

> Another way of looking at this is that right now we have
>
> - build-essential -- functionality you can assume is there
>
> - package upon which you build-depend
>
> but your proposal, if I've understood it correctly, is to add a level in
> between: functionality you can assume is there but nevertheless you
> should build-depend on a package providing that functionality.

Thanks for considering it.  It sounds like there isn't will to migrate
away from netbase in Build-Essential, and if that will materializes
later then it's easy to start then.  It's also possible that at that
point we'd want a different way to declare this kind of build
requirement instead of build-dependencies.  So simply adding netbase
to build-essential today sounds good to me.

Thanks,
Jonathan

Bug#904729: Policy 12.5: Must the license grant be included in debian/copyright?

[Jonathan Nieder]

Hi,

Markus Koschany wrote:

> FYI: Here is what one of the ftp-masters, Jörg Jaspert, wrote in
> response to my proposal to reduce boilerplate in debian/copyright.
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883950#80
>
> I believe it shows the generally tendency that they are in favor of the
> proposal.

Agreed: my understanding is that ftp-masters are fine with the
reference to common-licenses being implicit.

Simon McVittie wrote:

>   ( ) the full text of the license, *and* the license grant
>   (unless the license *is* the license grant, like BSD-style licenses)

This wording confuses me.  All licenses are license grants.  The issue
with having a (non-copyright-format) copyright file that simply states

|  On Debian systems the full text of the GPL-2 can be found in
|  /usr/share/common-licenses/GPL-2

is that that is just an irrelevant statement of fact; it doesn't tell
the reader what the license of the package is!  On the other hand,

| Files: *
| License: GPL-2+
|  On Debian systems the full text of the GPL-2 can be found in
|  /usr/share/common-licenses/GPL-2

in combination with

| Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

makes the intention very clear; the only potential icing on the top
would be if there were some file for users explaining how to interpret
this file.

Thanks,
Jonathan

Bug#905251: debian-policy: 4.9 paragraph is unclear (incompatibles statements)

[Jonathan Nieder]

Hi,

Clément Hermann wrote:

> 4.9 states:
> The package build should be as verbose as reasonably possible.
> This means that ``debian/rules`` should pass to the commands it
> invokes options that cause them to produce maximally verbose
> output.
>
> "as verbose as reasonably possible" seems incompatible with "maximally verbose
> output", at least in some cases (golang packages come to mind).
>
> Would it be possible to clarify this ?

Thanks for reporting.  My understanding from
https://bugs.debian.org/628515 is that the intention is

- print out compiler driver command lines, so that compiler errors are
  closely preceded with the command that produced them

- no need to print out command lines for tools like ld that are
  themselves invoked by the compiler driver, but do print out those
  command lines if you invoke them directly

I don't think verbosity for the sake of verbosity was ever a goal
here, so ideas for better wording would be very welcome.

In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=628515;msg=30
I proposed wording along the lines of

terse

Compiler and linker commands used to build the package
should not be abbreviated in the log unless this
tag is supplied.

Packages built with cmake, autotools, or
the Linux kernel build system can implement this by
passing the parameters V=1 and
VERBOSE=1 by default as arguments to
make and omitting them when the terse tag is
supplied.


I am not sure why this suggestion got generalized to "as verbose as
reasonably possible" in the patch that replaced it.

Thanks and hope that helps,
Jonathan

Bug#905251: debian-policy: 4.9 paragraph is unclear (incompatibles statements)

[Jonathan Nieder]

Hi,

Sean Whitton wrote:
> On Wed 01 Aug 2018 at 10:47PM -0700, Jonathan Nieder wrote:

>> Thanks for reporting.  My understanding from
>> https://bugs.debian.org/628515 is that the intention is
>>
>> - print out compiler driver command lines, so that compiler errors are
>>   closely preceded with the command that produced them
>>
>> - no need to print out command lines for tools like ld that are
>>   themselves invoked by the compiler driver, but do print out those
>>   command lines if you invoke them directly
>>
>> I don't think verbosity for the sake of verbosity was ever a goal
>> here, so ideas for better wording would be very welcome.
>>
>> In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=628515;msg=30
>> I proposed wording along the lines of
[... wording snipped ...]
> IIRC my hope was to generalise the recommendation to apply to as many
> different build systems as possible.  For example, packages whose builds
> do not involve any compilers and linkers.
>
> We could restore your text in a footnote or a "For example ..."
> paragraph?

Thanks.  Unfortunately, that wouldn't address Clément's concern about
maximal verbosity (1) not being consistent with reasonableness and (2)
not being concrete enough to easily act on as a packager.

Can we make it about not abbreviating build command lines, instead of
maximal verbosity?  For example, enabling more warnings might make a
compiler produce more verbose output, but it isn't the goal of this
requirement.  Similarly, enabling compiler tracing might make a
compiler produce more verbose output, and some people might even like
that, but I don't believe that was the goal of this policy
requirement.

Hope that helps,
Jonathan

Bug#905251: debian-policy: 4.9 paragraph is unclear (incompatibles statements)

[Jonathan Nieder]

Sean Whitton wrote:
> On Thu 02 Aug 2018 at 12:16PM +0800, Clément Hermann wrote:

>> "as verbose as reasonably possible" seems incompatible with "maximally 
>> verbose
>> output", at least in some cases (golang packages come to mind).
>>
>> Would it be possible to clarify this ?
>
> Yes.  Let's improve this.
>
> Would s/maximally// be sufficient?  Or s/maximally/more/ ?

I don't know a better way to say this, so I'll just say it: I am not
feeling listened to.  I am feeling talked past.  No, that wouldn't be
sufficient at all.

I think some of that is inevitable in the rush to resolve policy bugs,
but there are other ways to get this done that are less dismissive (for
example, requesting a patch).

If you'd like more detail from me, is there some appropriate place to
discuss this in real time?  I am jrnieder on freenode.

Jonathan

Bug#883950: Next steps on "[GPL-3+]" proposal

[Jonathan Nieder]

Hi,

Markus Koschany wrote:

> I personally dislike the trend in Debian to create more and more
> complexity in our source packages. I find the Standards-Version field
> unnecessary, VCS fields should not be part of a debian/control file, all
> DFSG licenses approved by our ftp-team should be listed in
> /usr/share/common-licenses and maintainers allowed to reference them,
> simple clarifications for copyright format 1.0 elements should not
> require a separate document 1.1 and so on.

Is this a trend?  Most of the complexity you are describing has been
there since day one, and efforts like the copyright format have tended
toward simplification.

> I have noticed that you are always in the opposite camp and a proponent
> for more complexity.

This is uncalled for, when Russ was just providing some context.

Please, let's discuss the proposals, not the people.

Sincerely,
Jonathan

Bug#904729: Policy 12.5: Must the license grant be included in debian/copyright?

[Jonathan Nieder]

Hi,

Simon McVittie wrote:
> On Wed, 01 Aug 2018 at 19:23:09 -0700, Jonathan Nieder wrote:
>> Simon McVittie wrote:

>>>   ( ) the full text of the license, *and* the license grant
>>>   (unless the license *is* the license grant, like BSD-style licenses)
>>
>> This wording confuses me.  All licenses are license grants.
>
> In the past, it has been asserted that maintainers are required to
> paste the text written by upstream that tells the consumer that they
> may redistribute the package under a specified license, verbatim,
> into the copyright file. That's what I meant whenever I said "license
> grant" on this bug. (Not to be confused with the text you can find in
> /usr/share/common-licenses, which tells you what the terms of the GPL
> are, but does not tell you that you can distribute any particular piece
> of software under those terms.)

Right: this involves a strange intersection of two requirements.

One is policy's "verbatim" requirement:

Every package must be accompanied by a verbatim copy of its
copyright information and distribution license

Another is a "common sense" requirement, which I'll put in my own
words:

A statement about where you can find a copy of the GPL does not
say anything about whether this package is under the GPL.  So
we need more than that.

One way to handle them both is to include a verbatim copy of some text
from upstream indicating that the package is under the GPL.  This is
what Joerg used to encourage packagers to include, for example in the
reject FAQ.

But since then, he has (fortunately!) relaxed a bit, and his more
current statements suggest that he views these two requirements as
independent.  We need a verbatim copy of the license, for example as
included "by reference" from common-licenses.  And we need a clear
indication that that license applies to this package, as provided for
example by the text

Files: *
License: GPL-2+

in a DEP-5 format copyright file.

Cc-ing him to allow him to correct me.

Thanks and hoping that clarifies,
Jonathan

Bug#905401: permit access to apt repositories during builds

[Jonathan Nieder]

Hi,

Ian Jackson wrote:

> Apropos of discussion in #813471:
>
> Paul writes:
>> In addition, d-i relies on access to the apt repo for the system.
>> I can imagine other uses of that, so I added a carve-out for that.
>
> In general I think this should be done by saying that packages may
> access the apt repository.  Binaries, and sources, because packages
> cannot depend on each others' sources and implementing that is a lot
> of work.
>
> See
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813471#126
> for a more extended rationale for permitting access to sources
> as well as binaries.

My feeling is that this should be an outside-policy carveout, since it
makes many applications (e.g., analyzing the build graph, especially
when needed for bootstrapping) no longer possible.

That said,

[...]
> --- a/policy/ch-source.rst
> +++ b/policy/ch-source.rst
> @@ -288,6 +288,13 @@ For packages in the main archive, no required targets 
> may attempt
>  network access, except, via the loopback interface, to services on the
>  build host that have been started by the build.
>  
> +Nevertheless, required targets may use ``apt`` to access the apt
> +repositories provided by the build environment (which are those which
> +were used to resolve the package's build-dependencies).  If
> +appropriate, :ref:`Built-Using `` must then be
> +declared.  It is permitted to download both binaries and/or sources.
> +However, this facility should not normally be used.
> +
>  The targets are as follows:

Seconded.

This doesn't mean I like the change.  It just means that I think this
reflects the outcome of the discussion you cited.  My understanding is
that the current policy process doesn't require me to check that the
main relevant stakeholders among those who haven't spoken up have
weighed in, since they can propose additional changes to address any
harms.

Thanks and hope that helps,
Jonathan

Bug#905401: permit access to apt repositories during builds

[Jonathan Nieder]

Ian Jackson wrote:
> Jonathan Nieder writes ("Re: permit access to apt repositories during 
> builds"):

>> My feeling is that this should be an outside-policy carveout, since it
>> makes many applications (e.g., analyzing the build graph, especially
>> when needed for bootstrapping) no longer possible.
>
> I don't really agree with the basic concept of an "outside-policy
> carveout".

That's reasonable.  Tool authors may want to know what they can count
on, and using policy to document what we need to support, even when it is
for a small number of special-case packages, can be useful for that
purpose.

One way to limit the harm is to be more explicit about this being a
discouraged practice, for example by naming the limited set of use
cases where we permit it.

> Also, this is the only way to implement many important and
> useful things.

Can you list some of them?

You mentioned the Xen package not wanting to bother package
maintainers to introduce -source packages to build-depend on, and I
don't find this particularly compelling --- most package maintainers
don't feel bothered when a feature request comes with a patch. ;-)  On
the other hand, I do agree with a related reason: a -source package
that is only useful for satisfying build-depends clutters up the
package list and makes it harder for a system administrator to find
the packages they need.

So I'd be very happy to see a way to declare a Build-Depends on a
source package.

The udeb case seems similar --- it's working around a lack of support
for declaring a Build-Depends on a udeb.

Am I understanding correctly?  Can we handle the full set of use cases
with some improvements in what Build-Depends supports?

> But I think you do have a legitimate concern.  I think we probably
> want to add a mechanism for a package to declare (eg in its buildinfo
> or changes maybe?) what it got from apt.  What do you think ?

If we're going that far, I think we might as well do a before-the-fact
declaration in Build-Depends.

>> Seconded.
>
> Thanks.

Thank you for writing the patch.  Even despite what I've written
above, having the existing practice documented seems preferable over
leaving it undocumented.

Sincerely,
Jonathan

Bug#905401: permit access to apt repositories during builds

[Jonathan Nieder]

Josh Triplett wrote:

> Why don't we make a specific exception for d-i in the short term, in the
> hopes that in the long term we'll have a way to handle dependencies on
> sources

Thanks, that makes a lot of sense to me.

I retract my second in message #13, but I'd be happy to review a patch
that provides a more targeted carve-out to support existing practice
without making the problem worse.

I also would be happy to see a separate thread to discuss expanding
supported packages that can be put in build-deps, for example as an
email thread in debian-boot@ or as a wishlist bug against dpkg with
debian-boot and a...@packages.debian.org cc-ed.  If I understand
correctly, it's a little different from build-time deps because there
is not a standard way to install a udeb or deb on the build system.

Thanks and hope that helps,
Jonathan

Bug#905453: debian-policy: Policy does not include a section on NEWS.Debian files

[Jonathan Nieder]

Hi Elana,

Elana Hashman wrote:

> NEWS.Debian files are listed in the "unofficial policy"[1] but not in
> the official policy.
>
> It seems this was proposed in 2002[2], but in 2003, folks were
> hesitant to "[get] this into policy until enough stuff uses it that we
> can tell it works well".
>
> Is 15 years long enough? Can we make this official?

It would be a welcome addition!  Do you have ideas for wording?

Thanks,
Jonathan

> [1]: 
> https://www.debian.org/doc/manuals/developers-reference/ch06.en.html#bpp-news-debian
> [2]: https://lists.debian.org/debian-devel/2002/07/msg00267.html
> [3]: https://lists.debian.org/debian-devel/2003/07/msg00286.html

Bug#905251: debian-policy: 4.9 paragraph is unclear (incompatibles statements)

[Jonathan Nieder]

Hi,

Sean Whitton wrote:
> On Thu 02 Aug 2018 at 07:29PM -0700, Jonathan Nieder wrote:

>> Thanks.  Unfortunately, that wouldn't address Clément's concern about
>> maximal verbosity (1) not being consistent with reasonableness and (2)
>> not being concrete enough to easily act on as a packager.
[...]
> Hmm.  The original goal of the requirement might well have been not
> abbreviating build command lines, and I agree that package maintainers
> should avoid abbreviating those.  However, ISTM that a more general
> recommendation in favour of verbosity is also useful, and should not be
> removed.  An example that comes to mind is test suite output: you really
> do want that to be quite verbose in order to see what went wrong.
>
> We have to rely on maintainer judgement about what to include.

Thanks for explaining your point of view.  I agree with relying on
maintainer judgement, and the best way to do that is to avoid having a
requirement in policy at all in some areas.

I think it really does help to look at the motivating use cases.  If
we focus on what it would be a good idea for a packager to do, then
policy would become very long, and it would become much less useful as
a precise source of information about Debian's packaging policies.
Instead, I find it more useful to focus on the non-obvious bits where
having a documented policy can help.

If I understand correctly, you're saying that the following fall into
that category:

- don't abbreviate build commands unless DEB_BUILD_OPTIONS=terse
- don't abbreviate test commands and output unless
  DEB_BUILD_OPTIONS=terse

Do I understand correctly?  Are there more examples in that category,
or could we just document those two?

[...]
> 1) Add something like "In particular, build command lines should not be
>abbreviated."  Then we are not leaving that particular case up to
>maintainer judgement, without removing the general recommendation.

This wouldn't help Clément's motivating example, since it would not
clarify whether there is additional verbose output he needs to
provide.

> 2) Add some examples of what should usually not be included, or perhaps
>just say that if some output makes a build log tens of megabytes in
>size, it should not be included.

I feel that this is trying to solve a problem that doesn't need
solving: packagers generally have good taste, and for most purposes it
is obvious to packagers what outputs they need to include (after all,
the packager is the primary audience of these logs!)  Build command
lines really are a special case since they are important to the
toolchain maintainers.

The size threshold you mentioned would suggest that the Linux kernel
should not support unabbreviated build logs.

> 3) Deal with the 'maximally' problem with one of the rewordings I
>suggested in a previous message -- we want to include mention that
>it's debian/rules that does the work of enabling the reasonable
>verbosity.

Removing 'maximally' might help, but it doesn't significantly change
the basic problem of the current text not being tightly scoped or
providing clear guidance.

Thanks and hope that helps,
Jonathan

Bug#905251: debian-policy: 4.9 paragraph is unclear (incompatibles statements)

[Jonathan Nieder]

Hi,

Clément Hermann wrote:
> On 03/08/2018 04:23, Sean Whitton wrote:
> > On Thu 02 Aug 2018 at 12:16PM +0800, Clément Hermann wrote:

>>> "as verbose as reasonably possible" seems incompatible with "maximally 
>>> verbose
>>> output", at least in some cases (golang packages come to mind).
>>>
>>> Would it be possible to clarify this ?
>>
>> Yes.  Let's improve this.
>>
>> Would s/maximally// be sufficient?  Or s/maximally/more/ ?
>
> IMO, s/maximally// would definitely fix the most pressing matter here,
> that is, the fact that we have incompatible statements. I would
> definitely be able to declare the go packages I maintain compliant, for
> instance.
>
> However, regarding the rest of the discussion on this bug, I agree more
> guidance to the maintainer as to what is expected would be nice. But
> that is a separate issue, I think.

Ah, thanks!  Sorry to have misunderstood.

I don't believe s/maximally// changes the normative content --- it just
more clearly expresses what it already is saying.  So I think a policy
editor can make that change without waiting for seconds.

Anyway, just in case, seconded.

Thanks,
Jonathan

Bug#883950: Next steps on "[GPL-3+]" proposal

[Jonathan Nieder]

Hi,

Ian Jackson wrote:
> Russ Allbery writes ("Bug#883950: Next steps on "[GPL-3+]" proposal"):

>>  Currently, copyright-format
>> 1.0 requires either that every License stanza in a Files paragraph contain
>> some "license text" in the copyright-format text (which may just be the
>> common-licenses pointer) or that there be a later stand-alone License
>> paragraph with the same short license identifier that has that text.  This
>> proposal breaks that property by introducing the possibility of a short
>> license identifier with no accompanying text.  This will require parser
>> changes.
>
> It will require parser changes in some, but not all, parsers.
>
> Changing the version would involve parser changes in all parsers.

I don't follow.  Why wouldn't a non-validating parser be able to simply
ignore the Format field?

Thanks,
Jonathan

Bug#906901: debian-policy: Perl script shebang requirement is disturbing and inconsistent with rest of policy

[Jonathan Nieder]

Hi,

Dominic Hargreaves wrote:
> On Tue, Aug 21, 2018 at 08:42:11PM -0700, Russ Allbery wrote:

>> I do feel like allowing either based on the whim of the packager is just
>> kind of bad.  It produces inconsistent behavior to no real benefit for
>> anyone.  If you install a Perl earlier in your PATH, you get totally
>> unpredictable behavior, and everyone will be unhappy half the time.
>
> My personal view is that the rule is the correct one though. Installing
> a different perl for some application specific purpose is not uncommon -

In this thread, there are three possible rules proposed:

 1. #!/usr/bin/env perl
 2. #!/usr/bin/perl
 3. Packager decides between 1 and 2, policy doesn't express a
preference.

The passage you are quoting is about the confusing user experience
that (3) provides: when someone installs a different perl to $PATH,
some Debian packages would use it and others wouldn't, with no
organizing principle to predict how each new package will behave.

I believe you are arguing for (2) as a long-term goal: all Debian
packages would then use /usr/bin/perl instead of the perl from $PATH,
while the sysadmin's own custom scripts using '#!/usr/bin/env perl'
would use perl from $PATH.  I agree with you that that's a good place
to end up, similar to what we already do with python.

Ian and Russ also mentioned that there's a bit of an inconsistency in
spirit here with policy 6.1:

  Programs called from maintainer scripts should not normally have a
  path prepended to them. [...] These considerations really apply to
  all shell scripts.

But as Ian mentioned, commands exist on a spectrum; most interpreters
are at an extreme end where hard-coding the path in *packaged scripts*
is generally the right policy, while commands like ls or git, say, are
at the other extreme where hard-coding the path would not accomplish
much useful.

So while this distinction between the interpreter of a script and
commands invoked within a script may feel arbitrary, in practice it
seems to work out pretty well.  Best of all, it's predictable.

For some other languages (#!/usr/bin/env node?), matching convention
might lead us to a different conclusion, and that's okay.

tl/dr:

- in the short term, I agree that this should be lowered to a policy
  "should", not "must"

- for the sake of the long term, I agree that debhelper should rewrite
  to the #!/usr/bin/perl form

Thanks,
Jonathan

Bug#907051: Say much more about vendoring of libraries

[Jonathan Nieder]

Hi,

Sean Whitton wrote:
> On Thu 23 Aug 2018 at 12:27PM +0200, Alec Leamas wrote:

>> https://fedoraproject.org/wiki/Packaging:Guidelines#Bundling_and_Duplication_of_system_libraries
>
> Thank you for sharing this link -- it seems like Fedora have thought
> harder about this than we have, at least at the level of the whole
> project.
>
> We can't jump straight to something as involved in that, but threads
> like this on -devel suggest to me that Policy's discussing of vendoring
> needs to be expanded.
>
> In particular, Policy should explain /why/ bundling is best avoided, and
> the consensus that it sometimes has to happen should be noted, along
> with mention of registering bundled copies with the security team where
> appropriate.

My first instinct was that this belongs in devref, not Policy, since
it is more about the project than about consistency and
interoperability issues that directly affect packaging tools and user
experience.

But then I realized that the Debian Free Software Guidelines, for
example, are part of policy.  This topic would similarly be a good fit
for ch-archive.  Thanks for filing it.

Jonathan

Bug#907051: Say much more about vendoring of libraries

[Jonathan Nieder]

Hi,

Arnaud Rebillout wrote:

> During all this time when I was questioning myself on the reason to
> un-bundle, the only official documentation I found was the short
> paragraph in the Debian Policy [1], which is quite thin. Only now,
> through the thread in debian-devel, I discover that there is some more
> information in Wiki. I couldn't find this information when I needed it,
> but maybe I'm just not good at finding a needle in a haystack ;)

For reference, I think you're referring to

 https://wiki.debian.org/EmbeddedCodeCopies
 https://wiki.debian.org/UpstreamGuide#No_inclusion_of_third_party_code

Thanks for that.  It may be a good place to find text to reuse.

Jonathan

Bug#906901: debian-policy: Perl script shebang requirement is disturbing and inconsistent with rest of policy

[Jonathan Nieder]

Hi Russ,

Russ Allbery wrote:

> I'm looking for seconds for this patch to relax the current requirement
> back to a should.
[...]
> --- a/perl-policy.xml
> +++ b/perl-policy.xml
> @@ -533,7 +533,7 @@ $(MAKE) OPTIMIZE="-O2 -g -Wall"
>Script Magic
>  
>
> -All packaged perl programs must start with
> +All packaged perl programs should start with
>  #!/usr/bin/perl and may append such flags as
>  are required.
>
> diff --git a/policy/ch-files.rst b/policy/ch-files.rst
> index f31a3b4..bc87573 100644
> --- a/policy/ch-files.rst
> +++ b/policy/ch-files.rst
> @@ -186,7 +186,7 @@ All command scripts, including the package maintainer 
> scripts inside the
>  package and used by ``dpkg``, should have a ``#!`` line naming the shell
>  to be used to interpret them.
>  
> -In the case of Perl scripts this must be ``#!/usr/bin/perl``.
> +In the case of Perl scripts this should be ``#!/usr/bin/perl``.
>  
>  When scripts are installed into a directory in the system PATH, the
>  script name should not include an extension such as ``.sh`` or ``.pl``

Seconded.

Thanks,
Jonathan

Bug#911165: debian-policy: drop requirement to ship sysvinit init script with same name

[Jonathan Nieder]

Andreas Henriksson wrote:

> It seems obvious to me that the above policy snippet was written in a
> time when the universe revolved around sysvinit. In current day and age
> sysvinit itself would be an "Alternate init system". We could update the
> snippet to say that any package providing support for an alternate init
> system must also provide systemd units if we wanted to modernize this
> part of policy.

I don't follow: why would we need such a requirement, given that
systemd knows how to execute init scripts?

Bug#917431: debian-policy: virtual packages: logind, default-logind

[Jonathan Nieder]

Adam Borowski wrote:

> logind: an org.freedesktop.login1 D-Bus API implementation
> default-logind: distribution's default logind provider

Seconded.

I like this description because it doesn't make assumptions about how
many logind implementions there are or which is the current default,
which should make ongoing maintenance of the docs easier.

Sincerely,
Jonathan

Bug#917995: debian-policy: drop section 1.6 Translations

[Jonathan Nieder]

Hi,

Marc Haber wrote:
> On Wed, Jan 02, 2019 at 12:29:50PM +0900, Ansgar Burchardt wrote:

>> I hereby propose to drop section 1.6 Translations and the following
>> sentence: "When translations of this document into languages other
>> than English disagree with the English text, the English text takes
>> precedence."
[...]
> Please don't do this. While appreciating the effort the translators
> make to improve Debian's useability, the quality of the translations is
> sometimes bordering on sounding like satire. I cannot judge for any
> other languages than German though.
>
> Policy being a technical document, and most, if not all technical things
> in Debian require some proficiency in English, I'd instead propose
> dropping translations for Policy and other documents that are targeted
> at developers and package maintainers.
>
> It is important to have (good!) translations for users, the effort going
> into translating developer-only documents should better go in our user's
> direction.

Thanks to both of you for helping frame this discussion.

Section 1.6 of policy is interesting to me for other reasons.  Its
function is to make Debian policy usable as a normative document.
That leads me in a few directions:

 1. There is no reason in principle that policy in another language
could not serve just as well in that capacity, as long as it is of
sufficient quality and well reviewed.  We could change this
section to list criteria for a version of policy to have normative
status --- e.g.

 a. in a language understood by at least one of the policy editors
 b. unilateral changes to that version are only made by policy
editors or their explicit delegates
 c. non-unilateral changes following the usual process of review
on the policy list to gather seconds from a Debian Developer

 2. There is something very idealistic about treating policy as a
standards document.  In practice, even in English, it has not been
air-tight enough for that, and has worked best as a part of a
system that includes the ability to get help interpreting it from
the policy list.

In that context, would removing section 1.6 be so bad?  We could
add a note to section 1.1 to help people parsing standardeses to
understand the best way to resolve confusing or ambiguous
passages: instead of trying to read deeply into confusing
language, file a bug and work with release managers and/or policy
editors to get it clarified.

 3. I would be against removing section 1.6 without a change along the
lines described in (1) or (2) above happening at the same time.

 4. I think this is a quite valuable proposal to have made.  Thanks
for that.

Thanks and hope that helps,
Jonathan

Bug#932696: Please document Haskell team style Vcs-Git sytax

[Jonathan Nieder]

Hi,

Ian Jackson wrote:
> Russ Allbery writes:

>> So, maybe something like:
>>
>>  -b  [; = ...]
>>
>> to build off of what we already have?  (With, obviously, a bunch of that
>> syntax marked as optional.)  If we ban "=" in , we can allow for
>>  to be optional but some other key/value pair to be provided.
>
> SGTM.  We can specify that [ ] contains optional information.

Taking a step back, I'd like to understand the use case a little better.

In Subversion, it's standard to use paths to represent multiple projects
and even branches within a repository.  So in that setting, I completely
understand why  is part of the URL.

In Git, when you "git clone" a repository, that represents a single
codebase.  There is no parameter you can pass to "git clone" that
tells it to clone just a subdirectory.  So we aren't including the
 in Vcs-Git in order to determine what parameters to pass to
"git clone".

Given that, what *are* we including the  for?  And similarly,
what is the use case behind the other key/value pairs described here?

It's possible that it might make sense to use separate fields for this
information --- e.g. a

  Vcs-Git-Path: 

or something like that.  That way, you get extensibility for free.

Alternatively, maybe there is a lurking Git feature request here, for
example for an atomic view across multiple repositories, or for the
ability to clone just a subdirectory of a repository (with
https://crbug.com/git/2 you already almost have that, though it's
fussy to set up sparse checkout to do it and you still have to "cd"
into the subdirectory).

Curious,
Jonathan

Bug#932696: Please document Haskell team style Vcs-Git sytax

[Jonathan Nieder]

Russ Allbery wrote:

> If you want to do what vcswatch is doing (analyze the current code
> repository for Debian packaging for commits that haven't been uploaded),
> and the team is, like Haskell, using a single repository for all the
> packages, you need to be able to find that specific package in the
> repository to look for unreleased changes.

Thanks.  Once someone writes some proposed text, it seems like it would
be worth mentioning this kind of use case in it.

> Similarly, dgit presumably wants to be able to find the part of the
> repository that's used for packaging a specific package, and I assume Ian
> is thinking about doing some dark magic to make that work with the rest of
> dgit's workflow (although I don't know what that is, or how it would work
> with, e.g., dgit tagging).

*nod*

>> And similarly, what is the use case behind the other key/value pairs
>> described here?
>
> We don't know, but we've now had to add two different things we didn't
> anticipate, and so it seems like a reasonable assumption there may be
> more.

For command line options like "-b", I would be okay with following the
same model as last time and using space as a source of extensibility
(i.e., breaking compatibility).  So for that I wouldn't want to use
the bracket syntax.

For future settings in the same spirit as  that don't involve
command line options, or for command-line options that are okay to
ignore, the

  Vcs-Git-Whatsit: 

approach should work okay.

So I'm thinking the bracketed path might be enough here, without need
for the additional complexity of in-field key/value pairs.

[...]
> Being able to clone a subdirectory of a Git repository would be lovely,
> speaking as someone who works at a company that insists on using a
> monorepo.

Interesting.  That's helpful context.

>I think that's a pretty long-standing feature request, though.

No one's filed it at bugs.debian.org/git or https://crbug.com/git yet.
But there's a similar internal feature request at $DAYJOB.  Thanks for
indulging my questions.

Jonathan

Bug#949006: debian-policy: Stop recommending stamp files in debian/rules

[Jonathan Nieder]

Hi!

Niels Thykier wrote:

> I would like to propose that we drop or replace the following
> recommendation in Policy:
>
> """
> When a package has a configuration and build routine which takes a
> long time, or when the makefiles are poorly designed, or when build
> needs to run clean first, it is a good idea to touch build when the
> build process is complete. This will ensure that if debian/rules build
> is run again it will not rebuild the whole program. [11]
> """
>
> (And related footnote about using "build-stamp" instead of "build").
[...]
> As I understand it, the primary purpose behind this recommendation
> comes from the need for running "debian/rules build && fakeroot
> debian/rules binary" and thereby repeating the build step in some
> cases (as listed in the text).

I don't have a strong opinion about what we should recommend to do
with poorly-designed makefiles (e.g. wouldn't it make sense for us to
work with upstream to make them less poorly designed?), but I think
this bug report is not characterizing the motivation correctly.

The motivation is the same as the motivation for rules to be
idempotent in any Makefile: it allows one to safely run steps in any
order, rerun them without unnecessary work, and so on.

In other words, this is a quality of implementation issue that affects
all developers working with the source package, not just buildds.  If
we switch to a policy that focuses only on buildds working, that would
take away a large part of what I find appealing about working within
Debian.

> However, with the advent of Rules-Requires-Root many packages can now
> be built with a direct "debian/rules binary" call and here the stamp
> file is no longer useful for the above purpose.
>
> Furthermore, debhelper need some complexity in implementing/emulating
> this behaviour.  This may sound "easy" until you try to implement this
> "correctly" for the following sequence of debian/rules calls:
>
>  debian/rules build-arch
>  debian/rules binary-indep
>
> This has resulted in debhelper using arcane trickery such as log files
> (up to compat 9) and its own "stamp-log" (compat 10+).  Both
> techniques have their limitations and causes frustrations for people
> that has a "well-behaving" upstream build system as they have to work
> around debhelper's trickery.
>
> Notely, this trickery prevents you from hacking on the upstream parts
> and use "dpkg-buildpackage -b -nc -uc -us" to reduce the build times
> for subsequent builds.  You would have to add some rm -f calls to
> delete "internal debhelper state files" as well between each
> dpkg-buildpackage call.

The ideal is to have dependencies correctly set so that if something
changes, the build system knows exactly what needs to be rebuilt.  Is
that achieveable in the debhelper context?

Summary: I don't have a strong opinion about what policy should say to
do with poorly-designed makefiles, but let's make sure debhelper
doesn't enter that category.

Thanks,
Jonathan

Bug#949007: debian-policy: Typo in example

[Jonathan Nieder]

Niels Thykier wrote:

> In
> https://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules-gainrootapi
> we find the following example:
>
> """
> Examples of valid use of the gain root command:
>
> # sh-syntax (assumes set -e semantics for error handling)
> $DEB_GAIN_ROOT_CMD some-cmd --which-requires-root
>
> # perl
> my @cmd = ('some-cmd', '--which-requires-root');
> unshift(@cmd, split(' ', $ENV{DEB_GAIN_ROOT_CMD})) if $ENV{DEB_GAIN_ROOT_CMD};
> system(@cmd) == or die("@cmd failed");
> """
>
> The Perl code is invalid.  There is missing a 0 after "==" and before "or 
> die(...)".

(I don't think this is normative, so probably not needed, but just in
case:)

Seconded.  Thanks for catching it.

Sincerely,
Jonathan

Bug#949006: debian-policy: Stop recommending stamp files in debian/rules

[Jonathan Nieder]

Niels Thykier wrote:

> debhelper cannot see "inside" the upstream build system.  If you modify
> a .c file, debhelper won't notice and will currently just skip the
> entire build.  Alternatively, debhelper will have to invoke the build
> system and rely on it to not be flawed.

Yes, I think that would be a good behavior (invoking the build system
and if it's flawed, let the packager work with upstream on it).
Especially because the effect is directly on the packagers --- buildds
wouldn't be hurt by this, as you note.

Is that the proposed debhelper change?  Where can I sign up? :)

> AFAICT, the current practise recommended by policy have the same issue
> (assuming you implement the stamp file or touch the "build" file).

Right, using "touch build" or build-stamp is a last resort, for
dealing with irreperable upstream build systems.  Having a proper
upstream build system is much better (and isn't all that rare).

Thanks,
Jonathan

Bug#953629: debian-policy: Please permit Debian revisions with 1.0 native packages

[Jonathan Nieder]

Hi,

Sam Hartman wrote:

> I think there are at least two cases where this issue comes up and is
> important, and where using a debian revision without separate upstream
> tarballs is the right approach:
>
> 1) small packages currently maintained by the upstream maintainer where
> debian revision is incremented for packaging only changes and upstream
> revision is incremented for upstream versions
>
> and
>
> 2) Cases typically outside the Debian archive where a git tree is being
> built as a Debian package especially as part of a CI system and where
> the effort of tracking upstream tarballs is undesired.
>
> 2) is more of an issue for lintian than it is for debian-policy.

I don't have any strong opinions about this, but I got the impression
that Ian's motivation is a different case 3):

| Most packages are maintained in git nowadays.  It is usual to have a
| separate git branch for Debian and upstream work.  In such a situation
| it makes perfect sense to have an upstream version number which
| corresponds to an upstream tag.  For packages with a very small (or
| zero) Debian delta to the upstream files, it makes sense to maintain
| these git branches using `git merge' rather than as a stack of
| patches.
|
| However, there are serious inherent problems with all of the
| non-native source formats.  There are many that can occur in git
| repositories which are not representable in non-native packages.  For
| example, changes to symlinks.  Worse, one must either choose
| `3.0 (quilt)' which involves patch files within the git tree
| and a great deal of complexity to manage those; or 1.0-with-diff which
| has an even more restricted set of things it can represent.

Regardless of what happens to the 1.0 format, shouldn't the non-native
package formats be improved to handle this?  The "git diff" format,
which GNU patch has reasonable support for, is able to represent all
of these kinds of changes, including changes to symlinks.  Tooling for
handling 3.0 (quilt) packages is reasonably good at generating an
appropriate single-diff quilt at build time.  To the extent that this
doesn't work, it seems worth fixing.

Thanks,
Jonathan

Bug#954794: New packages must not declare themselves Essential

[Jonathan Nieder]

Josh Triplett wrote:
> Jonathan Nieder wrote:
>> Josh Triplett wrote:

>>> This change does not propose eliminating the concept of Essential, nor
>>> does it propose that any specific package become non-Essential.
>>
>> I think I'd be more supportive of this change if it did.  Freezing the
>> current essential set in time feels oddly unpragmatic.  If we had a
>> plan, even one that would take a while, to shrink the essential set,
>> then it would be more likely to feel worth the cognitive load.
>
> Long-term, I'd like to see that happen. But I'm a huge fan of
> incremental steps; defining the problem as "eliminate Essential" makes
> it both difficult enough and controversial enough to make it unlikely to
> happen at all. Right now, the first step is "let's not let the problem
> get any worse, and let's ensure that any new package that might have
> otherwise used Essential must instead get packages to add a dependency".

In consensus building and implementation, I agree with you: I like to
see work in incremental steps, and it's not necessary to get full
consensus for the full plan in advance.  After all, we can learn as we
go and would need to change the plan.

Even so, some *rough* consensus on the plan is very useful for helping
people evaluate that first step.  It also gives people confidence that
it can still move forward even if some people involved no longer have
time to carry it forward themselves.  In this example, I think we
agree about the ideal first (freeze the current Essential set) and
last (eliminate Essential) steps but we don't have a clear picture of
what happens in between.  That makes it hard to be comfortable with
the first step because there's no reason to be confident that we'll
get any further than that.

If we don't have a rough plan, then the current state already seems
okay: whenever someone proposes adding new Essential functionality, we
can discuss it on debian-devel and the most likely outcome is that it
gets rejected.

Some next steps that would make me more comfortable with an explicit
freeze on Essential:

- document how to mark a package as "not safe in normal circumstances
  to uninstall" (such as apt and systemd-sysv).  Is "Priority:
  important" enough or should one use more?  As a package maintainer,
  how do I mark a package as something that a user would never want to
  deinstall in normal circumstances?

- some rough idea about how to find undeclared dependencies.  Do we
  do an NMU to add currently Essential packages as Pre-Depends on all
  packages and then unmark them as Essential and let package
  maintainers sort it out?  Is there some autodetection we can do
  using autopkgtest?

- some rough idea about what to do with packages from outside the
  Debian archive.  Do we provide a way to declare implicit Pre-Depends
  for everything from a particular archive?

To be clear, I'm not saying we need to commit to a plan (and I'm
certainly not saying it should be documented in policy), but a rough
sense of whether this seems possible and whether there are people
interested in moving it forward would help build consensus for the
first step.

Thanks,
Jonathan

Bug#954794: New packages must not declare themselves Essential

[Jonathan Nieder]

Javier Serrano Polo wrote:
> On Wed, 30 Sep 2020 18:34:06 -0700 Jonathan Nieder 
> wrote:

>> Even so, some *rough* consensus on the plan is very useful for
>> helping people evaluate that first step.
>
> Here is a rough plan:
>
>1. Policy: Packages should declare all their dependencies, even
>   essential ones.

I agree: this is the right first step.

More specifically, it's the right first three steps.

https://www.debian.org/doc/debian-policy/ch-binary.html#dependencies
currently says

Packages are not required to declare any dependencies they
have on other packages which are marked Essential (see below),
and should not do so unless they depend on a particular
version of that package.[4]

[4] [...] If packages add unnecessary dependencies on packages
in this set, the chances that there will be an unresolvable
dependency loop caused by forcing these Essential packages to
be configured first before they need to be is greatly
increased.

I'd propose that as a first step we change that to

Packages are not required to declare any dependencies they
have on other packages which are marked Essential (see below),
but are permitted to do so even if they do not depend on a
particular version of that package.[4]

[4] Functionality is rarely ever removed from the Essential
set, but packages have been removed from the Essential set
when the functionality moved to a different package. So when
depending on these packages for such functionality, it is
recommended to depend on an appropriate virtual package
instead.

Future versions of Debian policy may encourage and then
require including explicit dependencies even for essential
functionality. This is helpful to users putting together
ultra-minimal systems (though Debian does not support omitting
Essential functionality out of the box), and it means less
work is required in case the moment comes to remove some
functionality from the Essential set in the future.

(The next two steps would be to change that from "are permitted" to
"should", and then to "must".)

What do you think?

Thanks,
Jonathan

[4] "Essential is needed in part to avoid unresolvable dependency loops
on upgrade. If packages add unnecessary dependencies on packages in
this set, the chances that there will be an unresolvable dependency
loop caused by forcing these Essential packages to be configured first
before they need to be is greatly increased. It also increases the
chances that frontends will be unable to calculate an upgrade path,
even if one exists.

"Also, functionality is rarely ever removed from the Essential set, but
packages have been removed from the Essential set when the
functionality moved to a different package. So depending on these
packages just in case they stop being essential does way more harm
than good."

Bug#954794: New packages must not declare themselves Essential

[Jonathan Nieder]

Hi,

Sean Whitton wrote:
> On Mon 16 Nov 2020 at 04:12AM +01, Guillem Jover wrote:
> > On Sat, 2020-11-07 at 13:30:13 -0700, Sean Whitton wrote:

>>> Could I ask you to explain your wanting to reduce the Essential set for
>>> the sake of small installation size in more detail, including some
>>> numbers, please?  It would be good to get to the bottom of Bill's worry
>>> about this change, but in addition, I would like to see a stronger
>>> positive case.
>>
>> I'm not sure about Josh, but I think the main reasons for wanting to
>> reduce the essential set are:
>>
>>   - Making chroots/containers slimmer, which can have a substantial
>> impact when needing lots of them, where even few MiB can make a
>> difference.
>>   - Making bootstrapping (build and installation) in general easier,
>> even though for the former these packages also need to then
>> be ideally removed from the build-essential set too.
>
> Thank you for this, but I was hoping for some more specifics.  For
> example, what are some examples of large Essential: yes packages that
> might actually, in practice, be removable?

See https://wiki.debian.org/Proposals/EssentialOnDiet: an example is
e2fsprogs, which is ~2.1 MiB.  (You might not consider that large, but
when you multiply that by "every Debian installation everywhere", it
adds up.)

https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=nonessentiale2fsprogs;users=helm...@debian.org
shows that people are already adding explicit dependencies on it,
which means that
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954794;msg=111 is
the de facto policy / what people believe policy to say.  (Which is a
surprise to me, but it's a useful signal.)

Thanks,
Jonathan

Bug#986320: Stronger advice on when to use native packages

[Jonathan Nieder]

Hi,

Russ Allbery wrote:

> Currently, Debian Policy is silent on when it's appropriate to use a
> native package, but there may be a project consensus aganist using
> native packages when the software has an existence outside of Debian.

I agree about this (modulo the bits discussed elsewhere in this bug
about using native packages as a workaround to issues with the format
of non-native packages).

> Even if that consensus does not exist, there is probably consensus
> that native packages are a poor match for large packages (because of
> the inefficiency of making small updates to the packaging of native
> packages),

Do you mean large packages with a separate upstream existence, or
large packages in general?  I don't think there's such a consensus for
large packages in general: if Debian is the canonical place for a
particular package to be released (e.g., as is true for dpkg), then it
doesn't seem like it would be worth the overhead of making two
releases, one upstream and one for packaging, whenever updating that
package.

[...]
> (See #542288 for some of this discussion.)

Because I'm lazy: :) that's a pretty long bug --- did you have a
particular comment in it in mind?

Thanks,
Jonathan

implementing /etc/mailname

[Jonathan Nieder]

Hi,

Some possibly silly questions.  Policy §11.6 recommends:

If your package needs to know what hostname to use on (for
example) outgoing news and mail messages which are generated
locally, you should use the file /etc/mailname. It will contain
the portion after the username and @ (at) sign for email
addresses of users on the machine (followed by a newline).

which allows

 - a single machine to have multiple fqdns (virtual hosts), the
   mail service being only one of them, or
 - mail to be taken care of by a different machine

Useful enough.  Unfortunately, implementing that policy requires
Debian-specific patches that are more invasive than the nicer "use
'editor' in place of 'vi'" kind of changes from policy 11.4.  Results:

 - a larger delta from upstream, usually; complexity in code that only
   applies to Debian;
 - other operating systems miss out on this feature;
 - mailname support does not benefit from upstream testing.

Can we do better?  Has there been work on cross-distro standardization
of something like /etc/mailname?  Barring that, would there be
interest in a (Debian-specific) Debian-specific getmailname() function
to be used instead of patches like

- gethostname(default_email + len, sizeof(default_email) - len);
+
+ /* On Debian check /etc/mailname before using gethostname */
+ FILE *mailname = fopen("/etc/mailname", "r");
+ if (mailname && fgets(default_email + len,
+   sizeof(default_email) - len, mailname)) {
+   int l = strlen(default_email + len);
+   if (default_email[len+l] == '\n')
+ default_email[len+l] = 0;
+ }
+ else {
+   if (errno != ENOENT)
+ warning("unable to read /etc/mailname: %s\n",
+strerror(errno));
+   gethostname(default_email + len,
+ sizeof(default_email) - len);
+ }
+ if (mailname)
+   fclose(mailname);

?  To avoid slowing down app startup ("scripting performance") it
could be an inline function.


--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101213223220.ga31...@burratino

Re: fails to purge not RC

[Jonathan Nieder]

Hi,

Holger Levsen wrote:
> On Donnerstag, 16. Dezember 2010, Jonathan Nieder wrote:

>> Could you elaborate?  I would think that making "dpkg --purge" exit
>> with nonzero status would be serious, though perhaps of the can-defer
>> kind.
>
> It's annoying, it will probably leave cruft and it's a policy violation. But 
> that about it. The exit code is trivial to workaround (just expect that purge 
> will fail for some package, it's a safe bet) and there are basically no 
> consequences. (Except cruft on the system.) 

It means you cannot delete the old configuration and start over.
Sometimes packages include configuration that affects other packages
in the system (e.g., init scripts) and the ability to purge them
really is functionally important.

> At the end of this the dpkg database is in an ok state.
>
> So IMO nothing serious. Important, yes.

Ok.  I checked policy and all I can find on the subject is

Each script must return a zero exit status for success, or a
nonzero one for failure, since the package management system
looks for the exit status of these scripts and determines what
action to take next based on that datum

which leaves us with only common sense to decide the question "what
about maintainer scripts that never succeed?".  So policy agrees with
you.

(Breaking this feature of the packaging system is an important bug but
it seems it was never declared release-critical.  I am fine with that,
on reflection.)

>>> (Plus 27 packages, which even fail to install - but see #595652 for why I
>>> stopped filing those as serious atm and see
>>
>> Failure to install noninteractively sounds less severe[1] than failure
>> to purge.
>> [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=20;bug=595652
>
> You should have continued until msg=30 and 52 ;-) 

Of course I read the whole log.

> In short: failing to install non-interactivly is ie a problem for automated 
> installations and live-media builds. IOW: in getting the software deployed, 
> not getting rid off it. 
>
> At the end of this the dpkg database is _not_ in an ok state.
>
> That seems more severe to me.

I don't agree, especially because policy states the opposite directly
in §6.3.  In any event, it is hard to find an example of either of
these (broken noninteractive preinst or postinst, broken purge) that
is not a sign of major breakage.

Thanks for a useful clarification.
Jonathan


--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101218092554.ga7...@burratino

doc-base revisited

[Jonathan Nieder]

Hi,

Since 2005 (452a1383), policy has recommended registering
documentation with doc-base.  I'd like to revisit that recommendation,
see how well it is working, and discuss whether we can make it better.

Aron Xu wrote[1]:

> To be honest, I don't see the necessity to register those fcitx
> documentations to doc-base, resons:
>
> 1. Users and developers who are interested in fcitx are required to
> have an X11 environment (fcitx is a X input toy). If so, I think
> nearly all of them will find the documentations themselves and open
> them with a browser (or text editor) to view them (see 2 for reason).
>
> 2. Registering to doc-base won't benefit users of Yelp or something in
> same category.
>
> 3. Documentations about how to use doc-base is not so good, or we
> won't be dealing with this problem now.
>
> 4. The reason why I register them is to make lintian calm.

I also can say that as a user, I often have a better experience
browsing in /usr/share/doc by hand than using dwww.  Why is that?

 * The registered documentation is very sparse.  It is not obvious
where any given kind of information is to be found (the categories are
especially unhelpful and I suspect something more faceted like debtags
might do a little better).  Maybe it would be better to avoid
categorization altogether and make sure that the search features of
documentation browsers work well?

 * Most abstracts do not make it clear what the document is about.

 * The same document is registered multiple times.  I used to
find it especially annoying to find prerendered text versions of
manual pages listed alongside "chapter book" manuals (dwww and similar
tools are capable of translating manual pages themselves, so the
additional rendered versions seem redundant).

 * There is no clear separation between user-oriented documentation
(manuals) and developer-oriented documentation (design documents).

As a packager my complaints are fewer, and I am happy with the
opportunity doc-base registration provides to get to know the
documentation I am providing.

 * The doc-base specification is a bit cryptic.  It is especially
unclear what one is supposed to do with collections of text documents.

 * Registration can be a bit tedious.  I assume most READMEs do
not need to be registered, but why?  Maybe they should be registered
automatically?

As an idealistic solution, I would like to proposed the following:

 * Leave doc-base policy basically the same as today (though I'd be
happy to work on making it clearer with respect to details like text
file handling).

 * Treat some mailing list (debian-doc?) as the (unofficial?)
maintainer of doc-base registration files in all packages.  Whenever a
package gets new documentation, registrations would be proposed to
that list.  Maybe there could be a pseudo-package so bugs in doc-base
registration would go directly to that list.  This way there would be
some consistency and editorial control attached to the entire index of
documentation.

Does this sounds sane?  Would anyone like to help make it a reality
(maybe this would make sense as a new announced service or as a DEP)?

Jonathan

[1] http://bugs.debian.org/607498


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110111082747.gc9...@burratino

doc-base sections (Re: doc-base revisited)

[Jonathan Nieder]

Robert Luberda wrote:
> On 11.01.2011 09:27, Jonathan Nieder writes:

>>  * The registered documentation is very sparse.  It is not obvious
>> where any given kind of information is to be found (the categories are
>> especially unhelpful and I suspect something more faceted like debtags
>> might do a little better).
[...]
> There's a similar request in bug#171955, and in general it would be nice
> to have such thing implemented in both doc-base and frontends like dwww
> or dhelp. I'm aware that currently is quite hard for maintainer to
> choose the most appropriate section
[...]

Okay, I'd like to start with this.  Surely there is some cross-desktop
and cross-distro prior art for documentation categories, right?
[1][2][3][4][5][6][7]

Oh.  Well, what do yelp and khelpcenter4 do, then?

yelp has tables of contents in data/toc.xml and data/scrollkeeper.xml,
like so:

 
   Desktop
   Welcome to the GNOME Help Browser
   
 Accessibility
 Learn more about making your system more accessible for a 
range of disabilities
   
   
 GNOME Applications
 [...]

The categories are imho better in many ways than the current list from
doc-base.txt (e.g., it has a category for version control, which is
what I was last looking for) but they are far from perfect.  Seems to
be based on the XDG Menu specification[8].  Each document's rarian
metadata file includes a semicolon-delimited of categories from that
spec.

rarian's docs/rar-mdf.xhtml[9] describes the preferred metadata
format.  omf files work and the documentation says they are preferred
for compatibility, too.

KHelpCenter uses .desktop files, with a hierarchy of .desktop files
determining the hierarchy of documents displayed[10].

The toplevel table of contents:

 Welcome to KDE
 KDE Users' Manual
 Application Manuals (organized according to the menu spec)
 Control Center Modules
 KInfoCenter Modules
 Kioslaves
 Scrollkeeper - Additional non-KDE documentation
 Plasma Manual - documentation for the core interface
 Tutorials
 Unix Manual Pages (organized by section)
 Browse Info Pages (uses dir.info)
 The KDE FAQ
 Contact Information
 KDE on the Web
 Supporting KDE

Also notable is the X-DOC-Weight field, which allows "heavier" manuals
to be shown below "lighter" documents.

This sort of categorization seems quite valuable to me.  I would
like to separate

 - tutorials and how-to documents
 - papers/articles covering some specific topic in depth (still for
   users)
 - specifications (file formats, protocols, etc) and design documents
 - command-line reference (perhaps by requiring that such
   documentation be provided as man pages/info pages and not be
   registered separately)
 - API documentation
 - user manuals
 - GUI help collections

To start, it seems most important to separate the user manuals and GUI
help from the rest.  That is somewhat orthogonal to the application
hierarchy.  This could be achieved by adding a new (optional at first)
field to .doc-base files indicating what role the documentation is
meant to play.

> I agree, it would be a good idea to have some team to review the
> doc-base files, especially that something similar is already done for
> debconf templates and packages' descriptions.

Given a way to register translations (and translations of abstracts)
it should be easy to justify "volunteering" debian-l10n-english to
help with editorial control over the English version.  Maybe even
without (would have to ask).

Thanks, that was helpful.

Jonathan

[1] 2003-12-07: discussion on documentation system begins on xdg-list.
http://lists.freedesktop.org/archives/xdg/2003-December/001306.html
[2] 2003-12-10: "All I really need from the help system is a listing of
the documents installed, though having more metadata is
always better than less."
http://lists.freedesktop.org/archives/xdg/2003-December/001370.html
[3] 2004-01-04: "At this point, I've basically agreed on desktop files as
the metadata format."
http://lists.freedesktop.org/archives/xdg/2004-January/001488.html
[4] 2005-05-17: first draft of a help system spec based on .desktop files
http://www.freedesktop.org/wiki/Standards/help-system?action=recall&rev=1
[5] 2007-03-22: latest version of that help system spec
http://www.freedesktop.org/wiki/Specifications/help-system
[6] 2010-04-16: the latest spec, based on a /usr/share/help/ directory.
"This does not provide a mechanism for installing metadata
 files. I'm not really interested in doing that anymore, and
 nobody else seemed to want it either. I can go into reasons
 why I don't think it matters if anybody wants to hear it."
http://lists.freedesktop.org/archives/xdg/2010-April/011443.html
[7] 2010-05-07: more precisely:
"My

Re: tcl8.5 breaks dpkg-cross assumptions and multiarch

[Jonathan Nieder]

(please drop cc's other than debian-policy in replies if you want to
work on that)

Hi Wookey,

Wookey wrote:

> Debian policy (8.2) says:
> ---
> It is recommended that supporting files and run-time support programs
> that do not need to be invoked manually by users, but are nevertheless
> required for the package to function, be placed (if they are binary)
> in a subdirectory of /usr/lib, preferably under /usr/lib/package-name.
> If the program or file is architecture independent, the recommendation
> is for it to be placed in a subdirectory of /usr/share instead,
[...]
> For multiarch, or existing
> dpkg-cross cross-compiling, to work, arch-dependent needs to mean
> either form _or_ content (see below for elaboration).

I always had thought that it's content and that the "if they are
binary" is only a red herring.  I agree with you that the policy ought
to be clarified.  Thanks for bringing this up.

Regards,
Jonathan


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110131174653.GA31826@burratino

[PATCH resend] Correct unclosed start-tag introduced in 45cbe74

[Jonathan Nieder]

From: Charles Plessy 
Date: Sun, 16 Jan 2011 17:48:24 +0900

---
Hi Charles,

Charles Plessy wrote:

> I attached here a patch that corrects a syntax error introduced by one of my
> previous patches, applied last September (45cbe74). The policy in the current
> master branch (9b45eca) currently does not build for that reason.

Thanks for the fixup.  Bill or Russ, could you apply this?

Alternatively, is there another repository we should be working
against in the meantime?

 policy.sgml |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/policy.sgml b/policy.sgml
index f5e2e9d..1674034 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -2565,7 +2565,7 @@ Package: libc6
Source (mandatory)
Maintainer 
(mandatory)
Uploaders
-   DM-Upload-Allowed
+   DM-Upload-Allowed
Section 
(recommended)
Priority 
(recommended)
Build-Depends et 
al
@@ -2671,7 +2671,7 @@ Package: libc6
  Version (mandatory)
  Maintainer 
(mandatory)
  Uploaders
- DM-Upload-Allowed
+ DM-Upload-Allowed
  Homepage
  Standards-Version (recommended)
  Build-Depends et 
al
-- 


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110301081841.GA27436@elie

Re: [PATCH resend] Correct unclosed start-tag introduced in 45cbe74

[Jonathan Nieder]

Bill Allombert wrote:

> Done as 11ced50c61b4b242baa34428de74d93d64e846cd.

Thanks, Bill.  That was fast. :)


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110301233904.GB9490@elie

Bug#599944: [PATCH] Add a reminder of Pre-Depends policy to §7.2 "Binary Dependencies"

[Jonathan Nieder]

Section 3.5 says:

 You should not specify a Pre-Depends entry for a package before this
 has been discussed on the debian-devel mailing list and a consensus
 about doing that has been reached.

Add a reminder of this to section 7.2, where the semantics of
Pre-Depends are discussed in more detail.

Requested-by: Mattias Ellert 
Fixes: http://bugs.debian.org/599944
Signed-off-by: Jonathan Nieder 
---
Mattias Ellert wrote:

> I therefore suggest that the paragraph about Pre-Depends in section 7.2
> is amended with a cross-reference to the rule in section 3.5 about the
> requirement about establishing a consensus on debian-devel.

Something like this?  Please feel free to improve on it.

 policy.sgml |9 -
 1 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/policy.sgml b/policy.sgml
index 6e04c81..1684f78 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -1090,7 +1090,7 @@
 
   
 
-  
+  
Dependencies
 

@@ -4774,6 +4774,13 @@ Build-Depends: foo [linux-any], bar [any-i386], baz 
[!linux-any]
package.  It is best to avoid this situation if
possible.
  
+
+ 
+   You should not specify a Pre-Depends entry for a
+   package before this has been discussed on the
+   debian-devel mailing list and a consensus about
+   doing that has been reached.
+   See .

  

-- 
1.7.4.1




-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110301235848.GA11460@elie

Bug#601839: debian/rules: reword build-arch, build-indep one line fix

[Jonathan Nieder]

user debian-pol...@packages.debian.org
severity 599944 wishlist
retitle 599944 debian-policy: please clarify section 4.9 "build-arch 
(optional), build-indep (optional)"
usertags 599944 + informative issue
quit

Hi,

For those following along at home, we are discussing section 4.9 "Main
building script: debian/rules", the paragraph concerning "build-arch
(optional), build-indep (optional)".

anatoly techtonik wrote:

> - The build target should depend on those of the targets build-arch
> and build-indep that are provided in the rules file.
> + The build target should depend on build-arch and build-indep targets
> if they are provided in the rules file.
>
> Please, correct me if its wrong, but please make the wording more simple.

I believe the intent is as follows:

 - if both build-arch and build-indep are provided, the build target
   would depend on both;
 - if build-arch is provided but not build-indep, the build target
   would depend on build-arch;
 - if build-indep is provided but not build-arch, the build target
   would depend on build-indep;
 - if neither build-indep nor build-arch is provided, the build target
   is just fine. :)

In other words, the current wording takes into account that only one
of the build-{arch,indep} targets might be provided while your
proposed wording does not.

I believe the current wording has a similar problem already:

“A package may also provide both of the targets build-arch and
build-indep.”

It would be clearer to say “A package may also provide one or both of
the targets build-arch and build-indep.”  Like so, perhaps?

-- 8< --
Subject: Clarify that providing build-arch without build-indep (or vice versa) 
is allowed

The current policy is that the build-arch target, if provided, is
sufficient for building architecture-dependent packages and the
build-indep target, if provided, will take care of the
architecture-independent ones; and that people building a package can
fall back to using the build target if the more specific relevant
target fails with status 2.

So it is allowed and perfectly sensible to make a build-arch target
without a build-indep target to go along with it.  Tweak the wording
slightly to avoid suggesting otherwise.

Inspired-by: anatoly techtonik 
Signed-off-by: Jonathan Nieder 
---
 policy.sgml |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/policy.sgml b/policy.sgml
index 6e04c81..fcafdf4 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -1943,7 +1943,7 @@


  
-   A package may also provide both of the targets
+   A package may also provide one or both of the targets
build-arch and build-indep.
The build-arch target, if provided, should
perform all the configuration and compilation required for
-- 
1.7.4.1




--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110302005552.GA11586@elie

Bug#609160: debian-policy: include DEP5

[Jonathan Nieder]

user debian-pol...@packages.debian.org
severity 609160 wishlist
usertags 609160 + packaging
quit

Hi Charles,

Charles Plessy wrote:
> Le Thu, Jan 06, 2011 at 09:49:17PM +, Lars Wirzenius a écrit :

>> Attached please find a patch that adds a copy of DEP5 to the
>> debian-policy package.
[...]
> if adding a third markup language to the debian-policy package is discouraged,
> I offer to convert the markdown file to debiandoc. Please ping me if 
> necessary.

Ping :).  I would be interested in either a copy in debiandoc format
or rules in the Makefile to build from docbook format.  If interested
in the latter, please coordinate work using Bug#175064.

Thanks much,
Jonathan



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110302011357.GB12046@elie

Bug#613143: there is /usr/lib64 symlink but no /usr/local/lib64

[Jonathan Nieder]

user debian-pol...@packages.debian.org
severity 613143 wishlist
usertags 613143 + normative discussion
quit

Hi Matthias, Aurelien, Santiago,

Tollef Fog Heen wrote:

> Suggested change:
>
> --- /proc/self/fd/13  2011-02-13 09:12:50.142239544 +0100
> +++ policy.sgml   2011-02-13 09:12:01.565231567 +0100
> @@ -5993,6 +5993,13 @@
>to get access to kernel information.
>  
>
> +  
> +
> +  The requirement for /usr/local/lib
> +  to exist if /lib or 
> +  /usr/lib exists is removed.
> +
> +  

See http://bugs.debian.org/612000 for context.  In short,
because (upstream, non-Debian) GCC searches all .../lib64 directories
before .../lib directories, the search order is out of wack if a
/usr/local/lib64 symlink does not exist:

 - /usr/local/lib64 (which does not exist)
 - /usr/lib (because /usr/lib64 is a symlink to it)
 - /lib (because /lib64 is a symlink to it)
 - /usr/local/lib
 - /usr/lib again
 ...

That is, /usr/lib gets higher precedence than /usr/local/lib.

The technical question before us is whether the libc6 package (or
base-files or something) should provide a /usr/local/lib64 -> lib
symlink to get out of this mess.

Any thoughts?
Jonathan



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110302013154.GA12160@elie

Bug#604397: debian-policy: require build-arch and build-indep targets

[Jonathan Nieder]

user debian-pol...@packages.debian.org
usertags 604397 + normative discussion
quit

(please consider dropping policy Bug#604397 or dpkg-buildpackage Bug#229357
from replies)
Hi,

Roger Leigh wrote:
[out of order for convenience]

> Just for the record, I've implemented support in debhelper's dh
> command in #604563.  Once applied, this will automatically add support
> to the huge chunk of the archive using "tiny" rules files.  cdbs will
> be next on my list.

debhelper 8.1.0 has such support now.  Thanks!

>> * Roger Leigh , 2010-11-21, 21:38:

>>> I'd like to propose that build-arch and build-indep be changed in
>>> Policy from "may be provided" to "must be provided" in preparation
>>> for enabling their use.

Personally, I'm all for it; ideally it would happen in the following
order:

 1. Providing build-arch and build-indep becomes a best practice.
lintian gains a check.  devref encourages the practice.

 2. Becomes a policy "should".

 3. Becomes a policy "must".

That sounds slow, no?  Yes, that's the point.  I'd like to propose
that we not make most of the packages in the archive instantly RC
buggy, today.

>>> We've wanted to fix the root problem for
>>> at least half a decade, and I'd like to get it done for wheezy.

I just noticed this gem in policy §4.9:

If one or both of the targets build-arch and build-indep are
not provided, then invoking debian/rules with one of the
not-provided targets as arguments should produce a exit status
code of 2.  Usually this is provided automatically by make if
the target is missing.

So it seems to me that "dpkg-buildpackage -B" ought to be taught to
run the equivalent of

debian/rules build-arch
if test "$?" = 2
then
debian/rules build
fi

.  In http://bugs.debian.org/72335 the only argument against that I
see is

(and notwithstanding that we're going to require both or neither), it
should say that "debian/rules -q with one of the not-provided targets
...", because the programs which will want to test this are likely to
do something cheap like:

debian/rules -q build-arch
if [ $? -eq 2 ]; then
debian/rules build
else
debian/rules build-arch
fi

To try a full build only to receive an exit status of 2 would not say
whether the build failed or the target was not found.

That doesn't seem so compelling to me; in the failure case, the
autobuilder would just try to pick up where it left off and fail
again, which doesn't sound so expensive.  What am I missing?

Thanks for moving this forward.

Regards,
Jonathan



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110302030131.GA26696@elie

Bug#609162: debian-policy: package names with dots/periods ('.') and crontab files: packagers beware

[Jonathan Nieder]

user debian-pol...@packages.debian.org
usertags 609162 + normative discussion
severity 609162 normal
quit

Hi Karl,

Karl E. Jorgensen wrote:

> The debian policy section 9.5 [1] suggests using the package name as a
> file name when creating files in /etc/cron.d, /etc/cron.hourly,
> /etc/cron.daily etc.  This works well *unless* the package name
> includes a dot ('.'), as this forces the file name to include a
> dot. And cron will ignore the files as a result.

Thanks for raising this.  I agree that we should change the advice

If a certain job has to be executed at some other frequency or
at a specific time, the package should install a file
/etc/cron.d/

to reflect the run-parts rule

If neither the --lsbsysinit option nor the --regex option is
given then the names must consist entirely of ASCII upper- and
lower-case letters, ASCII digits, ASCII underscores, and ASCII
minus-hyphens.

The current rule for package names (from §5.6.1) is

[a-z0-9][-+a-z0-9.]+

so the problematic characters are dot ('.'), which you mentioned,
and plus ('+').

You proposed to advocate substituting hyphens for dots, but that
would create problems when the names of two packages differ only
by punctuation:

great-package
great.package

Maybe we don't have to worry about such an insane case.  In any event,
it's easy to avoid that problem by substituting underscores for dots
and P for plus signs.

Sensible?  If so, would you like to propose wording for this?

Regards,
Jonathan



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2011030203.GA26879@elie

Bug#613046: debian-policy: please update example in 4.9.1 (debian/rules and DEB_BUILD_OPTIONS)

[Jonathan Nieder]

user debian-pol...@packages.debian.org
usertags 613046 + informative discussion
quit

Hi,

Julien Cristau wrote:
> On Sat, Feb 12, 2011 at 14:25:40 +0100, Niels Thykier wrote:

>> CFLAGS  = $(shell dpkg-buildflags --get CFLAGS) -Wall -g
>>
>> While related to #578597, I believe it to be a distinct issue. This was 
>> triggered
>> by this email[2] on debian-mentors.
>
> Seems to be the exact same request to me?

I believe they are different.  This request seems to be about
informative text (an example), while #578597 is about the normative
part of policy (a policy "should").

Here's a rough patch for discussion's sake.  Points that might be nice
to fit in somehow:

 - warning flags come before the flags read from dpkg-buildflags,
   so they can be overridden with
   DEB_CFLAGS_APPEND="-Wno-all -Wno-extra"

 - important optimization flags such as -fno-strict-aliasing
   come after the flags read from dpkg-buildflags, so they cannot
   be overridden

 - using := instead of = saves us from running dpkg-buildflags
   multiple times if $(CFLAGS) is used more than once.

Thoughts?  Improvements?
---
diff --git a/policy.sgml b/policy.sgml
index 242ac10..5814960 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -2256,18 +2256,13 @@
massage this example in order to make it work for your
package.

-CFLAGS = -Wall -g
 INSTALL = install
 INSTALL_FILE= $(INSTALL) -p-o root -g root  -m  644
 INSTALL_PROGRAM = $(INSTALL) -p-o root -g root  -m  755
 INSTALL_SCRIPT  = $(INSTALL) -p-o root -g root  -m  755
 INSTALL_DIR = $(INSTALL) -p -d -o root -g root  -m  755
 
-ifneq (,$(filter noopt,$(DEB_BUILD_OPTIONS)))
-CFLAGS += -O0
-else
-CFLAGS += -O2
-endif
+CFLAGS := -Wall $(shell dpkg-buildflags --get CFLAGS)
 ifeq (,$(filter nostrip,$(DEB_BUILD_OPTIONS)))
 INSTALL_PROGRAM += -s
 endif



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110302033836.GA27022@elie

Bug#613946: debian-policy: anchor issues in HTML version

[Jonathan Nieder]

user debian-pol...@packages.debian.org
clone 613946 -1 -2
retitle -1 debiandoc2html:  titles should not have embedded tags
retitle -2 debiandoc2html:  anchors should enclose heading text
severity -1 normal
severity -2 minor
reassign -1 debiandoc-sgml 1.2.20
reassign -2 debiandoc-sgml 1.2.20
usertags 613946 + packaging
quit

Hi Osamu,

Christoph Weber noticed:

> When you view the HTML version of the Debian Policy with a browser
> like Lynx or SeaMonkey/IceApe (which interpret  elements in
> the header), you'll notice some unfiltered tags like:
>
> | 4.4 Debian changelog: debian/changelog
> or
> | 7.2 Binary Dependencies - Depends
>
> Apparently,  and  etc. should be filtered out in the title
> text of the link elements.
>
> Another tight related issue are the anchors that serve as destination
> for those link elements.  Currently, they are declared like this:
>
> | 7.2 Binary Dependencies -
> | Depends, Recommends, Suggests,
> | Enhances, Pre-Depends
>
> There is no link text.  A better solution would be:
>
> | 7.2 Binary Dependencies -
> | Depends, Recommends, Suggests,
> | Enhances, Pre-Depends

See http://bugs.debian.org/613946 for more details.  Thoughts?

The following testcase[1] reproduces the problem.

Thanks,
Jonathan

[1] Usage: "debiandoc2html testcase.sgml".



  

  Example
  Authors



  About this manual


  Debian changelog: debian/changelog

  




-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110302042405.GA27306@elie

Bug#606869: debian-policy: Please fix freedesktop.org links

[Jonathan Nieder]

user debian-pol...@packages.debian.org
usertags 606869 + informative
quit

Hi David,

David Prévot wrote:

> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -8940,9 +8940,9 @@ name ["syshostname"]:
>  
>
>If the window manager complies with  - id="http://www.freedesktop.org/Standards/wm-spec";
> + id="http://www.freedesktop.org/wiki/Specifications/wm-spec";
>   name="The Window Manager Specification Project">,
> -  written by the http://www.freedesktop.org/";
> +  written by the http://www.freedesktop.org/wiki/";
>   name="Free Desktop Group">, add 40 points.
>

Thanks.  I think this is a non-normative change, since "The Window
Manager Specification Project written by the Free Desktop Group"
refers to the same documents regardless of what URI we use.

Re the first URI: I wonder if we should say something more precise,
like EWMH 1.3 .  That
would be a bigger change, though[1].

Re the second URI: it's a shame the main freedesktop.org site
hard-codes "wiki" in its address, but I suppose it's best to respect
their wishes.

Hope that helps,
Jonathan 

[1] Maybe it would be best to clone the bug and deal with that
separately.



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110302045345.GA27466@elie

Bug#587377: debian-policy: Decide on arbitrary file/path names limit

[Jonathan Nieder]

user debian-pol...@packages.debian.org
usertags 587377 + normative issue
quit

Guillem Jover wrote:

> This is not really a dpkg bug, the limitation is not actually coming
> from it, it's coming from the kernel and/or specific file system
> implementation. I don't consider it appropriate to add an arbitrary
> limit in dpkg itself, when it can handle long file/path names just
> fine.
>
> Given that this might cause problems depending on the different support
> from the build and host machines this should be considered a matter of
> policy, and as such “enforced” by lintian or ftp-master for example, if
> at all. I'm thus reassigning it to debian-policy, so that an arbitrary
> limit can be decided if desired.

This is a hard one.  I agree that dpkg shouldn't enforce this (though
perhaps it could recover better).

 * _POSIX_PATH_MAX is 256.  _POSIX_NAME_MAX is 14 (yikes).
 * _XOPEN_PATH_MAX is 1024.  _XOPEN_NAME_MAX is 255.
 * Linux PATH_MAX is 4096.
 * NTFS's maximum path length is 32768.
 * naive file access in Windows has a maximum path length of 260.
 * the maximum path length on this laptop[1] is 170:

[...]/src/gcc/[...]/ \
MBeanServerPermission$ \
MBeanServerPermissionCollection$ \
MBeanServerPermissionEnumeration.class

To throw out a strawman, I suppose 256 characters should be a reasonable
maximum for paths in Debian packages.

I'd be happier with data from the lintian lab to support that.  Any
takers?

Thanks.
Jonathan

[1]
find / |
awk '
BEGIN {
maxstr = "";
maxlength = 0
}
length($0) > maxlength {
maxlength = length($0);
maxstr = $0;
print maxlength;
print maxstr;
}
'



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110302052738.GA27567@elie

Bug#609935: debian-policy: 5.2 should clarify how Hompage from the source and binary packages relate

[Jonathan Nieder]

user debian-pol...@packages.debian.org
severity 609935 minor
clone 609935 -1
retitle -1 policy: clarify precedence and propagation of Section and Priority
usertags 609935 + informative issue
usertags -1 + informative issue
quit

Hi,

Christoph Anton Mitterer wrote:

> The Homepage control filed is according to chapter 5.2 allowed in both,
> the source package and the binary packages paragraphs.
[...]
> But unlike with Section and Priority, it's not specified whether the binary 
> packages
> derive that from the Source package if it's specified there AND not overriden
> in the binary package paragraph.

Here's a survey of the current status.  I'll focus on Priority, since
Section uses almost identical constructions.

 §2.5 Priorities:
Each package should have a priority value, which is included
in the package's control record (see Priority, Section 5.6.6).

 §5.6.6 Priority:
When it appears in the debian/control file, it gives the value
for the subfield of the same name in the Files field of the
.changes file. It also gives the default for the same field in
the binary packages.

When it appears in the first (general) paragraph of debian/control or
a package-specific paragraph?  And does it give the default for the
package-specific paragraph or the corresponding field of
DEBIAN/control?

Unless I'm missing something, the text could be a lot clearer.
Thanks for a pointer.

Regards,
Jonathan



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110302071950.GA14081@elie

Bug#609160: debian-policy: include DEP5

[Jonathan Nieder]

Hi,

Lars Wirzenius wrote:

> Updating the patch should, I think, be done
> only after the draft is final and policy is ready to include it in the
> package (even if only in the policy VCS repository).

If you mean that there is no need to update to an intermediate
version, makes sense to me.  Anyway, getting any version ready to
include in the VCS (on a branch) seems worthwhile to me, and after
that, updating should be easy.

Caveat: I am only guessing (and faintly remembering some discussion)
about what formats are acceptable.  I just started working through
policy bugs a couple of days ago.  So please do not trust me. :)

> Converting the DEP5
> draft to whatever format is acceptable to policy should be fairly quick,
> only an evening's work or so. DEP5 should not require anything much in
> the form of markup, except tables (not sure if debiandoc supports
> tables).

debiandoc does not support tables.  That's one of many reasons policy
should eventually move away from it.

Maybe a  can work for the list of licenses in the short term?

> Having DEP5 wait for some docbook work in the debian-policy package
> would be unfortunate.

I can try this weekend to write some makefile rules to build from
docbook XML.  IMHO it would not be worth it to couple this with
converting policy.sgml itself.

Thanks,
Jonathan



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110302093322.GB14737@elie

Bug#604397: debian-policy: require build-arch and build-indep targets

[Jonathan Nieder]

(-cc: Bug#229357)
Jakub Wilk wrote:
> * Jonathan Nieder , 2011-03-01, 21:01:

>> So it seems to me that "dpkg-buildpackage -B" ought to be taught to
>> run the equivalent of
>>
>>  debian/rules build-arch
>>  if test "$?" = 2
>>  then
>>  debian/rules build
>>  fi
>
> make exits with code 2 "if any errors were encountered". So no, this
> approach cannot be used.

Did you read the rest of the message?

But okay, I am willing to accept that this is an approach we do
not want to use.  Which still leaves us with a number of options.

To help some existing packages today (and break others):

 1. Find an active "make" maintainer.
 2. Polish the patch in Bug#598534 and apply it.
 3. Use
make-first-existing-target build-arch build -- -f debian/rules

To help no existing packages today but make it easy for packages
to opt in (and not break the others):

 1. Introduce a Build-Options facility for packages to advertise
capabilities like this.
 2. Teach dpkg-buildpackage to honor it.

To move towards a world in which all packages support build-arch and
build-indep:

 1. Teach dpkg-buildpackage a new switch to use those targets.
The operator can easily figure out when they are available if
building by hand.
 2. Introduce a lintian test for build-arch/build-indep presence.
 3. Contribute patches.
 4. When there are not so many packages left without the feature,
propose a mass bug-filing/release goal.
 5. Finally, update policy and make autobuilders use the switch
to use those targets when building unstable and experimental.

Just my two cents,
Jonathan



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110302095943.GC14737@elie

Bug#609160: debian-policy: include DEP5

[Jonathan Nieder]

Lars Wirzenius wrote:
> On ke, 2011-03-02 at 03:33 -0600, Jonathan Nieder wrote:

>> If you mean that there is no need to update to an intermediate
>> version, makes sense to me.  Anyway, getting any version ready to
>> include in the VCS (on a branch) seems worthwhile to me, and after
>> that, updating should be easy.
>
> I don't think it makes sense to update to an intermediate version.
> Keeping two versions of the draft up to date is not something that I
> find a good use of my time, I'm afraid.

Sorry, I was unclear.  I meant that updating to the final version
when it's ready should be easy.

> Then I'll wait until someone who actually knows tells me the proper
> format.

Russ Allbery, active policy maintainer and currently swamped,
certainly knows.  He wrote the following, which can be found
earlier in this bug log:

I admit I'm not particularly thrilled about either of those
options; DebianDoc is fairly deprecated at this point, and
while Markdown is a lot simpler and easier to manage, adding a
third markup language, as mentioned, does raise the barrier of
entry a bit.

My long-term hope was still that we could all eventually move
to Docbook, but I've had zero time to work on that (or
anything else related to Policy lately).

I was only using common sense from there (since the topic seemed to be
stuck).  If an authority is really needed to move things forward,
maybe Bill can help?

> It's unfortunate that docbook (in any flavor) is so tedious to work
> with, both at the level of writing markup and the level of producing
> readable formats from the markup. If it is absolutely necessary, I'll
> use that, but I think it is a mistake for debian-policy to adopt docbook
> in any form.

What do you propose instead?  I think the problem seen with markdown
and its kin was that it is possible to accidentally trigger formatting
rules when talking about, say, the result from "echo `echo hi`".
That's not normally a big deal but it was mentioned as a possible
problem when you are writing a document that is meant to be normative.

> Perhaps it'd be easier to just use debiandoc for DEP5, for now.

Sure, that's why I presented both options.  Personally, I just want
to see this get done.

Regards,
Jonathan



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110302101240.GB15793@elie

Bug#587377: debian-policy: Decide on arbitrary file/path names limit

[Jonathan Nieder]

Sean Finney wrote:

> Having a warning in lintian for arbitrarily long (perhaps >= 256)
> filenames is totally reasonable i'd say, but there's no reason to
> otherwise throw out limits for the sake of having them.

Oh, I don't know.

Now that I check, the path provoking this was 269 characters
(including leading '.').  I'm able to install the package, both on
tmpfs and ext4, without trouble.  I suppose it would be interesting to
know: what was the environment like in which it failed to rename(2)?
E.g., what filesystem?

The ustar format only supports 256 character path names; but dpkg also
supports data.tar.gz using the GNU format, which supports longer.

Now I'm starting to worry that it might have been the length of the
filename rather than the pathname that triggered Bug#587440.  But the
filename was only 234 characters, which should certainly be safe, even
on filesystems like ubifs.  Ideas?

Puzzled,
Jonathan



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110302191122.GA19709@elie