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

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 t

Bug#954794: New packages must not declare themselves Essential

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 >>> nu

Bug#954794: New packages must not declare themselves Essential

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 declar

Bug#954794: New packages must not declare themselves Essential

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 suppor

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

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 i

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

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 w

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

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

Bug#949007: debian-policy: Typo in example

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 --whi

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

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 i

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

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 t

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

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 t

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

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 sh

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

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

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

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 p

Bug#907051: Say much more about vendoring of libraries

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

Bug#907051: Say much more about vendoring of libraries

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

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

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 PAT

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

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

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

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). >>> >>>

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

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

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

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". > >

Bug#905401: permit access to apt repositories during builds

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

Bug#905401: permit access to apt repositories during builds

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 n

Bug#905401: permit access to apt repositories during builds

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 th

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

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) >>

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

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 liste

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

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 im

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

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

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

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 possib

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

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 o

Bug#904248: Add netbase to build-essential

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 lo

Bug#904248: Add netbase to build-essential

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

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

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 th

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

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 rel

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

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 >

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

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

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

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:

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

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://w

Bug#515856: Debian Policy 4.1.4.0 released

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 enoug

Bug#515856: Debian Policy 4.1.4.0 released

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

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

(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 rep

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

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 l

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

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 with

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

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 wri

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

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: >>> >&g

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

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: >

Bug#688251: Built-Using description too aggressive

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`` > --

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

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 f

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

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 comp

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

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

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

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#G

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

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 'T

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

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 package

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

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 pack

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

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

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

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/ > Exa

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

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 > Exa

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

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 Se

Bug#459427: changelog vs. NEWS handling

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

Bug#459427: changelog vs. NEWS handling

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

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

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 t

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

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

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

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 Debia

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

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) def

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

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

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

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 real

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

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

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

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 >>

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

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 b

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

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/edito

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

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 usi

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

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 reade

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

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 se

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

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 profil

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

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 con

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

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,

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

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

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

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 depe

Bug#568374: debian-policy: section "8.4 Development files" not explicit enough regarding libraryname[soversion]-dev

Emilio Pozuelo Monfort wrote: > On Tue, 27 Oct 2015 10:06:50 +0100 Ansgar Burchardt wrote: >> I suggest to change >> >> | If there are development files associated with a shared >> | library, the source package needs to generate a binary >> | development package named librarynamesoversion-dev, or

Bug#767839: debian-policy: Linking documentation of arch:any package to arch:all

Hi, Robert Luberda wrote: > Please explicitly state in the Policy if linking > /usr/share/doc/arch:any_package to ../arch:all_package > (where arch:any_package and arch:all_package come > from the same source package) is allowed or not. It currently is not allowed. [...] > In my opinion, as

Bug#773557: debian-policy: Avoid unsafe RPATH/RUNPATH

Hi, Martin Carpenter wrote: >> 8.7 RUNPATH and RPATH >> >> Libraries and executables should not define RPATH or RUNPATH unless >> absolutely necessary. This part seems vague to me --- if a project relies on RUNPATH but could be modified to avoid relying on it, is today's use of RUNPATH absolutel

Bug#759260: removal of the Extra priority.

Hi, Charles Plessy wrote: > practically speaking, how do you or others use the Optional priority to check > that a package is not directly or transitively conflicting with another > package ? [...] > Can you give concrete examples where the Extra priority has been instrumental > for you as a use

Bug#196367: removal of the Extra priority.

(+cc: bug#196367, which proposes documenting overrides as authoritative) Bill Allombert wrote: > On Mon, Nov 17, 2014 at 02:29:46PM -0800, Jonathan Nieder wrote: >> Bill Allombert wrote: >>> Did you try to report the bug directly to the ftp-masters ? >>> If we deci

Bug#759260: removal of the Extra priority.

Bill Allombert wrote: > On Mon, Nov 17, 2014 at 01:59:37PM -0800, Jonathan Nieder wrote: >>And received >> pushback from maintainers that don't understand what the field is for, >> are confused about having to

Bug#759260: removal of the Extra priority.

Santiago Vila wrote: > In this case, however, I fail to see the rationale for actually > *dropping* the extra priority, other than "it's not useful for me". > Well, it may be useless for you but it's still useful for me. I have found the 'extra' priority to be useful personally, too. Enough so th

Bug#768292: debian-policy: please allow copyright file to refer to license text in separate files

Simon McVittie wrote: > My understanding is that Markus' question in that thread was orthogonal: > "is the exact license grant really required, or is the license itself > enough?" (for terminology see my reply at > ). > > I would also ap

Bug#768292: debian-policy: please allow copyright file to refer to license text in separate files

Hi, Simon McVittie wrote: > Some packages currently have stanzas like this in their copyright files: > > License: MPL-2.0 > The complete text of the Mozilla Public License 2.0 can be found in > the `MPL-2.0' file in the same directory as this file. > > It is not clear to me whether

Bug#758234: [PATCH] Remove priority "extra", make all corresponding packages priority "optional"

Ansgar Burchardt wrote: > Russ Allbery writes: >> In some cases, it can change maintenance decisions. > > Does this differ much from packages being picked up by other commonly > installed software? Say GNOME starting to depend on my small library > which suddenly raises from ~100 to 5+ report

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

Hi, Charles Plessy wrote: > Ansgar, you have written that you find the priority “extra” useful in some > situations, but for me it is not clear if the uses cases are for human > readability, or if it is to rely on that priority in automated processes. > Could you give us details ? There is proba

Bug#759186: debian-policy: please consider adding "nodoc" as a possible value for DEB_BUILD_OPTIONS to policy

Johannes Schauer wrote: > Quoting Jonathan Nieder (2014-08-25 20:35:34) >> Johannes Schauer wrote: >>> When bootstrapping, a common approach is to do a build without >>> documentation to be able to drop the build dependencies on documentation >>> building tools

Bug#759186: debian-policy: please consider adding "nodoc" as a possible value for DEB_BUILD_OPTIONS to policy

Hi, Johannes Schauer wrote: > please consider adding "nodoc" as a possible DEB_BUILD_OPTIONS value to > § 4.9.1 [1]. [...] > When bootstrapping, a common approach is to do a build without documentation > to > be able to drop the build dependencies on documentation building tools. This > is > wh

Bug#758234: [PATCH v2] Remove priority "extra", make all corresponding packages priority "optional"

Hi, Gerrit Pape wrote: > --- a/policy.sgml > +++ b/policy.sgml > @@ -852,17 +852,7 @@ zope. > install if you didn't know what it was and don't have > specialized requirements. This is a much larger system > and includes the X Window System, a full TeX > -

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

Hi Russ, Russ Allbery wrote: > Third, to address your concern about the process, what about consensus > review on debian-devel for any change in priority to required or > important (that is not a downgrade from required to important)? Consensus > review isn't the best process, since sometimes it

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

Hi, Ansgar Burchardt wrote: > I suggest to drop the following paragraph from 2.5: > > 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. > > This re

Bug#757274: devref: please point upstream to PTS subscription UI when forwarding bugs

Package: developers-reference Version: 3.4.13 An upstream package maintainer just gave the following suggestion: Given that it's so easy to subscribe to the PTS at qa.debian.org, why don't maintainers point that out to upstream when forwarding bugs? That way, if upstream wants to see reports with

Bug#555980: debian-policy: No policy on statically linked binaries

Hi, Russ Allbery wrote: > Usually I argue for relaxing it to a should. In this case, I think we can > flesh out the exception somewhat better and preserve the must. > > Binary executables must not be statically linked with the GNU C > library, since this prevents the binary f

Bug#555980: debian-policy: No policy on statically linked binaries

Hi, Bill Allombert wrote: > --- a/policy.sgml > +++ b/policy.sgml > @@ -8466,7 +8466,11 @@ fi > renamed. If a consensus cannot be reached, both > programs must be renamed. > > - > + > + Binary executables must not be statically linked with the > + G

Bug#742756: multi-arch and system-dependent header files

Bill Allombert wrote: > --- a/policy.sgml > +++ b/policy.sgml > @@ -6955,50 +6955,61 @@ Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1) [...] > + The requirement for C and C++ headers files to be > + accessible through the search path > + /usr/in

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

Bill Allombert wrote: > On Thu, May 08, 2014 at 12:51:05PM -0700, Jonathan Nieder wrote: >> FWIW I don't mind if you tweak the wording. >> >> Unfortunately it's not just = 32 or 64[1]. Luckily the only >> ones that would be relevant the way Debian uses are

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

Bill Allombert wrote: > On Thu, May 08, 2014 at 11:15:57AM -0700, Jonathan Nieder wrote: >> Thanks. Applied. > > Well, I was working on a patch that looks like: > > + The requirement for /usr/local/lib<qual> > +

  1   2   3   4   5   >