Bug#687900: document multiarch

Russ Allbery wrote: > There are various bugs already filed about some edge cases and > specific issues with multiarch, but none to track the general > documentation of multiarch handling in Policy. This bug will be > used to discuss the overall wording. To be precise, am I correct in assuming th

Bug#687900: document multiarch

Russ Allbery wrote: > I'd rather not do this piecemeal Fair enough. Thanks for filing the bug, by the way. -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://list

Bug#688251: dpkg-dev: Need to add support for Built-Using to dpkg-shlibdeps or new similar tool

Hi, Nicholas Bamber wrote: > Sorry yes I did not mean to imply that there was a copyright issue > with the inclusion of debhelper fragments in maintenance scripts, just > an example of techincally it might happen. The policy explicitly > mentions "incorporating source code". Based on

Bug#690293: Policy 5.6.24: Checksums-{SHA1,SHA256} are required by the archive software

Hi Charles, Charles Plessy wrote: > Subject: [PATCH] Checksums-Sha1 and Checksums-Sha256 are required by dak and > therefore mandatory > > Closes: #690293 > See also: http://bugs.debian.org/478295#73 > --- > policy.sgml |8 > 1 file changed, 4 insertions(+), 4 deletions(-) Thanks.

Bug#690495: [debian-policy] Prohibit click-through licenses or disclaimers

Hi Josh, Josh Triplett wrote: > Inspired by bug 689095, I'd like to suggest something like the following > as an addition to Debian Policy: > > = > Software in Debian should not prompt users to explicitly agree to > licenses, disclaimers, or terms of service in order to run that > software.

Bug#690495: Prohibit click-through licenses or disclaimers

Josh Triplett wrote: > On Wed, Oct 17, 2012 at 08:27:47PM -0700, Russ Allbery wrote: >> I do think this is iffy from a DFSG #7 perspective, since it's forcing the >> user to agree to the additional license, but I'm not sure we've ever >> discussed that in general. > > That thought crossed my mind

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

Michael Gilbert wrote: > On Sun, Jan 8, 2012 at 12:17 PM, Russ Allbery wrote: >> If I had to propose something, I'd propose +d60 or +dist60 for the >> stable/security updates, but there are probably better and more memorable >> terms than "dist". > > It sounds like +debXuY is now the plan for stab

Bug#694384: Clarify what first paragraph is in presence of blank lines

Hi Michael, Michael Tautschnig wrote: > At present, 213 packages fail to build using pbuilder, because they contain a > debian/control file starting with comment lines, then a blank line, then the > actual contents. This is caused by gnome-pkg-tools, as described in further > detail in #684503. [

Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification

Hi Ximin, Ximin Luo wrote: > I had been using the SVN for DEP as a baseline for patches, but now I guess > the > source code for this is somewhere else - could one of you please point me to > it? Sure. It's at . > Also, shall I continue on this bug report, or shall I start a thread on > debi

Bug#696185: [copyright-format] Please clarify what to use in License field for licenses not specifically mentioned

Andrew Starr-Bochicchio wrote: > --- a/copyright-format/copyright-format-1.0.xml > +++ b/copyright-format/copyright-format-1.0.xml > @@ -663,6 +663,14 @@ Copyright 2009, 2010 Angela Watts > license short names for unknown Format versions. > > > +For licenses which

Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification

Hi, Ximin Luo wrote: >> On 24/12/12 10:31, Charles Plessy wrote: >>> In particular, I do not see the benefit from using a syntax for the license >>> short names, [...] >>> If you would like to work on a >>> robust syntax, I propose you do it as an ind

Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification

Ximin Luo wrote: > I've split up my previous patch into more manageable chunks, and added > extra explanations in the commit messages. Thanks. I'm used to getting patch series in the mail, but I can adapt. | d6892294 - strip trailing whitespace Ack. | 4b752126 - change tri-license example to

Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification

Hi Charles, Charles Plessy wrote: > Le Tue, Dec 25, 2012 at 01:36:32PM -0800, Jonathan Nieder a écrit : >> For example, I think the idea of a License-exception stanza is >> uncontroversial and valuable. > > given that the current specification does not forbid unpecif

Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification

Charles Plessy wrote: > If experimentations are blocked because the current specification does not > allow unspecified types of paragraphs, how about considering to relax it ? I honestly think that License-Exception stanzas already are a fundamental enough change that they would have to be permit

Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification

Charles Plessy wrote: > Sorry for the confusion between new field and new paragraph. Still, I think > that we are spending a lot of time discussing refinements that need to > demonstrate their usefulness by being adopted independantly by a broad number > of package maintainers. Stepping back a l

Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification

Russ Allbery wrote: > It might be worthwhile to recognize some sort of syntax similar to license > exceptions so that one can tag the license as "BSD-3-Clause by holder>" or the like. That would let one use standalone license > paragraphs for those licenses without the ambiguity problem, while s

Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification

Ximin Luo wrote: > Why is it essential for the verbatim text to be in debian/copyright, > when the source package should already contain this? We could > alternatively add a Location: field to point to the verbatim license > in /usr/share/doc or the base directory of the source package, > rather t

Bug#649530: [copyright-format] clearer definitions and more consistent License: stanza specification

Russ Allbery wrote: > Jonathan Nieder writes: >> Russ Allbery wrote: >>> It might be worthwhile to recognize some sort of syntax similar to >>> license exceptions so that one can tag the license as "BSD-3-Clause by >>> " or the like. [...] >>

Bug#697134: [copyright-format] Introduce a syntax for BSD-3-Clause variants

Package: debian-policy Version: 3.9.4.0 Severity: wishlist Russ Allbery wrote[1]: > Jonathan Nieder writes: >>> Jonathan Nieder writes: >>>> Russ Allbery wrote: >>>>> It might be worthwhile to recognize some sort of syntax similar to >>>>>

Bug#693793: New virtual packages: lv2-host and lv2-plugin

Hi Alessio, Alessio Treglia wrote: > So, here is my proposal (which I've already posted on debian-devel): [...] > + lv2-hostanything that can host LV2 audio plugins > + lv2-plugin an LV2 compliant audio plugin Vincent Danjean wrote: > Le 21/11/2012 17:48, Ian Jackson

Bug#592610: 7.3/7.4/7.6: Usage of Breaks and Conflicts unclear and contradictive

retitle 592610 Clarify when Conflicts + Replaces et al are appropriate quit Hi Goswin, In 2010, Goswin von Brederlow wrote: > in May there was a discussion about the right use of Breaks or > Conflicts as part of Bug#582423, e.g. > http://lists.debian.org/debian-ctte/2010/05/msg00012.html Poli

Bug#697433: New field Package-List in .dsc

Russ Allbery wrote: > Charles Plessy writes: >> + >> + Package-List >> + >> + >> + Multiline field listing all the packages that can be built from >> + the source package. The first line of the field value is empty. >> + Each one of the next

Re: Bug#693477: psychopy: please specify full path of icon in /usr/share/menu/psychopy

pixmap.xpm in examples. + Thanks Yaroslav Halchenko. See #693477. + + -- Jonathan Nieder Thu, 10 Jan 2013 12:01:50 -0800 + menu (2.1.46) unstable; urgency=low * The "Marseille" release. diff --git a/doc/README.pre1 b/doc/README.pre1 index 20c2e32..c07c006 100644 --- a/do

Bug#697433: Is the Package-List field necessary for uploads ?

Charles Plessy wrote: > + > + Package-Type > + > + > + Simple field containing a word indicating the type of package: > + deb for binary packages and udeb for micro > binary > + packages. Other types not defined here may be indicated. In ud

Bug#697433: Is the Package-List field necessary for uploads ?

Russ Allbery wrote: > In response to the other follow-up, I don't think this is the right place > (or bug) to discuss udeb package behavior or what portions of Policy they > comply with. Surely it is relevant to people reading policy that it does not comply with them all (or in other words that t

Bug#698030: debian-policy: document micro binary packages (udebs).

Charles Plessy wrote: > actually the only section of the Policy that currently contains the string > 'udeb' is 8.6.4.2 about the shlibs system (plus some occurences in > introductory > parts earlier in the chapter 8). No bug in our list mention "udeb" either. > > I therefore am filing this new b

Bug#698030: debian-policy: document micro binary packages (udebs).

Charles Plessy wrote: > If you think that it is necessary to obtain the agreement of the d-i team to > mention the udebs in #697433, please go ahead, but on my side, I do not think > that there is a problem here. I guess I'm completely failing to communicate. udebs are already documented very cl

Bug#698030: debian-policy: document micro binary packages (udebs).

Bill Allombert wrote: > In that case there could be a udeb subpolicy document maintained by the > d-i team that policy would refer to. Yeah, that would be fine with me, even though I still don't see the point. Is there a git subpolicy describing how git is packaged? A gnome subpolicy about gno

Bug#698030: debian-policy: document micro binary packages (udebs).

Russ Allbery wrote: > I vote for just calling them "udebs" instead of "micro binary packages." > The latter sounds more formal, but I don't think anyone calls them that in > practice, so it may be confusing. Perhaps: > > udebs (stripped-down binary packages used by the Debian Installer) are >

Bug#698030: debian-policy: document micro binary packages (udebs).

Steve Langasek wrote: > The installer team are consulted on the > question of which packages should be made available as udebs, but for shared > libraries the maintenance of the udeb definitely lies with the library > maintainer, not the installer team. So it makes pe

Bug#671355: [debconf_spec] Document escape capability.

Hi Charles, Charles Plessy wrote: > while browsing in my pile of unanswered emails, I found that we lost momentum > on this issue. Can somebody have a look at the patch below and second if > appropriate ? Thanks for a reminder. >> Subject: [PATCH] Document Debconf's escape capability. A good

Bug#698030: debian-policy: document micro binary packages (udebs).

Hi, In January, Russ Allbery wrote: > I think we should probably say explicitly that they don't follow all of > the requirements laid out in this document. How about this patch? diff --git i/policy.sgml w/policy.sgml index 0347cd66..a41bc1fd 100644 --- i/policy.sgml +++ w/policy.sgml @@ -158,6

Bug#698030: debian-policy: document micro binary packages (udebs).

Hi, Charles Plessy wrote: > Le Sat, Mar 09, 2013 at 12:22:08AM -0800, Jonathan Nieder a écrit : >> + >> + >> + udebs (stripped-down binary packages used by the Debian Installer) do >> + not comply with all of the requirements discussed here. See the >

Bug#701081: debian-policy: mandate an encoding for filenames in binary packages

Russ Allbery wrote: > For me, allowing the correct spellings of > words and the correct names of things to be represented in file names is > important enough to rise to an ethical goal that I would advocate > adopting. This. Among the examples listed the only one

Bug#669915: debian-policy: §12.2 recommends possibly unneeded dependency (for Wheezy)

Charles Plessy wrote: > --- a/policy.sgml > +++ b/policy.sgml > @@ -1330,9 +1330,7 @@ zope. > The package installation scripts should avoid producing > output which is unnecessary for the user to see and > should rely on dpkg to stave off boredom on > - the part of a

Bug#688220: debian-policy: Typo in path to shlibs files in /var/lib/dpkg/info (8.6.4.1)

Charles Plessy wrote: > Le Sat, Sep 29, 2012 at 12:22:33PM +0200, Salvatore Bonaccorso a écrit : >> --- a/policy.sgml >> +++ b/policy.sgml >> @@ -6694,7 +6694,7 @@ Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1) >> The shlibs control files for all the >> package

Bug#701081: debian-policy: mandate an encoding for filenames in binary packages

Charles Plessy wrote: > after more than one month of discussion, we have not reached a conclusion. [...] > Can others comment how they would like to see this bug solved ? I think wording (requiring UTF-8 filenames) is probably the appropriate next step. Yes, maybe not everyone will agree on the

Bug#701081: debian-policy: mandate an encoding for filenames in binary packages

Charles Plessy wrote: > > File names > > > The name of the files installed by binary packages in the system > PATH > (namely /bin, /sbin, /usr/bin, > /usr/sbin and /usr/games/) must be encoded in > ASCII. > > > >

Bug#705403: Correcting non-standard dpkg states in the Policy.

Hi, Charles Plessy wrote: > Indeed... how about the following ? Mostly looks good. [...] > +++ b/policy.sgml [...] > @@ -4716,7 +4716,7 @@ fi >dependencies on other packages, the package names listed may >also include lists of alternative package names, separated >

Re: Built-Using, libgcc, and libc_nonshared

Russ Allbery wrote: >mksh-static of > course links statically and therefore pulls in substantial portions of > library source, but there are parts of libgcc and possibly libc that are > always incorporated into binaries, even ones that are dy

Bug#715804: Debian policy for web apps still references /doc as accessible

Charles Plessy wrote: > On my side, I think that the current practice is not to serve /doc by default, > and I therefore second the proposition of Thomas to remove point 2 of chapter > 11.5. > > Are there other seconds or objections ? Seconded. Thanks, Jonathan -- To UNSUBSCRIBE, email to deb

Bug#668394: debian-policy: Spurious virtual packages "mp3-encoder"/"mp3-decoder"

Charles Plessy wrote: > Le Mon, Apr 16, 2012 at 09:21:43AM +0200, Fabian Greffrath a écrit : >> As long as it is not possible to run "audio-encoder some_audio.wav" >> on Debian to convert some_audio.wav into the next best audio format, >> this virtual package makes no sense. This is especially tru

Bug#582109: debian-policy: document triggers where appropriate

Charles Plessy wrote: > Le Thu, Jul 25, 2013 at 08:00:55AM +0900, Charles Plessy a écrit : >> does the current patch (attached) address your concerns ? If yes, would >> you second it ? > > Hi all, > > I would like to make one more call for feedback. Sorry for the long silence. My feeling is tha

Bug#668394: debian-policy: Spurious virtual packages "mp3-encoder"/"mp3-decoder"

Charles Plessy wrote: > I went ahead and removed the mp3-decoder virtual package as well. The > changelog > now reads as follows. > > * virtual-package-names-list: removed mp3-decoder and mp3-encoder. > Seconded: Jonathan Nieder > Seconded: Kurt Roeckx >

Bug#688251: Built-Using description too aggressive

Hi, Charles Plessy wrote: > --- a/policy.sgml > +++ b/policy.sgml > @@ -5563,7 +5563,13 @@ Replaces: mail-transport-agent > > > > - A Built-Using field must list the corresponding source > + When the licensing terms of the incorporated parts require to provide > +

Bug#707077: obsolete conffiles: s/may/should/

Charles Plessy wrote: > Le Tue, Oct 15, 2013 at 03:07:29PM +0800, Paul Wise a écrit : >> On Mon, 2013-05-06 at 15:18 +0800, Paul Wise wrote: >>> In policy section 10.7.3 Behavior, there is this sentence: >>> >>> Obsolete configuration files without local changes may be >>> removed

Bug#707077: obsolete conffiles: s/may/should/

Charles Plessy wrote: > --- a/upgrading-checklist.sgml > +++ b/upgrading-checklist.sgml > @@ -62,6 +62,12 @@ Unreleased. > 9.1.1.8 >The exception to the FHS for the /selinux was removed. > > +10.7.3 > + During package upgrades, the removal of obsolete configuration files > + without loc

Removing obsolete configuration files on upgrade

Hi policy experts, Since policy 3.8.5.0, section 10.7.3 says Obsolete configuration files without local changes should be removed by the package during upgrade. I was trying to apply this to the git package and ran into a little trouble. Consider the following sequence of events

Bug#707851: Soften the the wording recommending menu files: let's do it in Jessie.

Hi, Steve Langasek wrote: > I believe we are at the point that we should be recommending a preference > for the fdo MIME interfaces Yep, and menus, too. Do we have clear advice about (1) how to write a menu entry for my console app (or niche graphical app) without cluttering the menus us

Bug#707851: Soften the the wording recommending menu files: let's do it in Jessie.

Charles Plessy wrote: > On the other hand, it is the spirit of Debian to accept low-maintenance > patches > (in that case, menu entries) when it can help other projects even if one does > not care for it. In that sense, if the Debian Menu has an active user base, > it > would be counter-product

Bug#707851: Soften the the wording recommending menu files: let's do it in Jessie.

Hi, Charles Plessy wrote: > please, I would like to decouple two issues. > > - Issue 1: the Debian menu is superseded in major destkotop environments, and >the Policy should recognise that the Debian menu is not the lead mechanism >for managing menus in Debian anymore. Unfortutately we

Bug#628515: recommending verbose build logs

Hi, Matthias Klose wrote: > This issue is now again silent for eight months. Is there anything missing, > or > any other reason why the issue doesn't see any progress? I believe there is a consensus that packages should produce verbose build logs by default and can optionally produce terse log

Bug#737559: copyright-format: author != copyright, add an author field?

severity 737559 wishlist user debian-pol...@packages.debian.org usertags 737559 = normative issue quit Hi Daniel, Daniel Pocock wrote: > Author and copyright holder are not always the same person/entity. [...] > License: GPL2 > Copyright: 2014, Acme, Inc http://acme.example.org > Author: Bob, ht

Bug#737559: copyright-format: author != copyright, add an author field?

tood that. Which is why I wrote > On 03/02/14 20:17, Jonathan Nieder wrote: >> So, I think this is a reasonable idea, and if more than two or so >> packages start using the field then it's probably worth documenting in >> policy to allow tools to start to consume it if t

Bug#737559: copyright-format: author != copyright, add an author field?

Daniel Pocock wrote: > I've only come across one package which included public-domain material > so far. In this case, I put a note about the author in the comments. Yep - that works, too. [...] > One risk of not having this extra field is that we could accumulate > excessive things in the Copy

Bug#694883: copyright-format: author != copyright, add an author field?

Just forwarding to bug#694883 ("please clarify the recommended form for public domain files") for easy reference. Thanks, Jonathan --- Begin Message --- On 03/02/14 20:55, Jonathan Nieder wrote: > Daniel Pocock wrote: > >> I've only come across one package which incl

Bug#685992: debian-policy: Document in the policy the way to properly set selinux labels on files and directories

Hi, Laurent Bigonville wrote: > A maintainer script can for example call the restorecon(8) executable > to achieve this: > [ -x /sbin/restorecon ] && /sbin/restorecon $myfile Should I do this for all files I create in maintainer scripts, or only those that someone who knows things :) has

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

Hi, 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. > > > +

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

tags 613143 = pending quit Russ Allbery wrote: > I second this as well, although I think it's unnecessary at this point. Thanks. Applied. -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive:

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

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#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#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#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#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#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#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: [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#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#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#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#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#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#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#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#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#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.

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#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#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#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#566220: [PATCH] Clarify "verbatim copy of its copyright and distribution license"

Hi, Steve Langasek wrote: > --- a/policy.sgml > +++ b/policy.sgml > @@ -570,7 +570,7 @@ > > > Every package must be accompanied by a verbatim copy of > - its copyright and distribution license in the file > + its copyright notices and distribution license in the file

Bug#566220: [PATCH] Clarify "verbatim copy of its copyright and distribution license"

Hi, Just wanted to clarify a few points from your message, out of order. No patch is attached to this message. I will probably download the policy sources and write one soon, if no one beats me to it. First a point you made towards the end: Steve M. Robbins wrote: > On Mon, Feb 01, 2010 at 11:5

Bug#566220: [PATCH] Clarify “copyright and distribution license”

as the information is there, it doesn’t matter if it has exactly the same formatting. For example, combining the dates from multiple copyright notices is a common practice. Signed-off-by: Jonathan Nieder --- Steve Langasek wrote: > I agree that "copyright information" vs. "cop

Bug#566220: [PATCH v2] Clarify “copyright and distribution license”

matter if it has exactly the same formatting. For example, combining the dates from multiple copyright notices is a common practice. Signed-off-by: Jonathan Nieder --- Hi Charles, Charles Plessy wrote: > Le Sun, Feb 07, 2010 at 09:33:29PM -0600, Jonathan Nieder a écrit : > > Packages must

Bug#566220: [PATCH] Clarify "verbatim copy of its copyright and distribution license"

Steve M. Robbins wrote: > On Sun, Feb 07, 2010 at 06:59:06PM -0800, Steve Langasek wrote: >> The motivation is to put an end to the contrafactual interpretation of this >> clause in Policy that Ben Finney continues to advance in discussions on >> Debian mailing lists. > > Really? The change is ai

Dependencies of pseudo-essential packages

[Please do not cc libblk...@packages on follow-ups.] Hi, As you may remember, about 10 years ago [1] the question of whether to treat all dependencies of essential packages as pre-dependencies came up. The result AFAICT was that this is a bad idea, since it doesn’t allow maintainers of essential

Bug#578597: Recommend usage of dpkg-buildflags to initialize CFLAGS and al.

Hi, Raphael Hertzog wrote: > With dpkg 1.15.7 just uploaded to sid, there's now a dpkg-buildflags > command that should be used to initialize CFLAGS, LDFLAGS, CPPFLAGS, > FFLAGS, CXXFLAGS. Neat tool; thanks for writing it. Even without the support of policy, policy already indicates an obvious

Bug#578597: Recommend usage of dpkg-buildflags to initialize CFLAGS and al.

Raphael Hertzog wrote: > On Wed, 21 Apr 2010, Jonathan Nieder wrote: >> Given that it will probably be a while before this tool is used >> universally, what benefit does an existing package with code like the >> above get from switching to using dpkg-buildflags? > > It

Bug#566220: [PATCH] Clarify “copyright and distribution license”

user debian-pol...@packages.debian.org usertags 566220 + seconded thanks Hi, Jonathan Nieder wrote: > --- a/policy.sgml > +++ b/policy.sgml > @@ -569,8 +569,8 @@ > Copyright considerations > > > - Every package must be accompanied by a verbatim

Bug#545688: Basic webapp packaging questions

Hi Sean, Thanks for the answers. In particular: sean finney wrote: > i think that makes sense. as for location, official debian policy says > you could drop files in /usr/lib/cgi-bin, though myself i'm not a huge > fan of that as a general rule since the scripts are able to be run as > soon as

Bug#504880: Disambiguate "installed" for packages

Hi, Russ Allbery wrote: > This adds new information to the "Summary of ways maintainer scripts are > called" section (6.5) stating exactly what maintainer scripts can depend > on when various actions are called. This is very welcome. Thanks for moving it forward. Warning: most of what I say be

Bug#504880: Disambiguate "installed" for packages

Hi again, Continuing where I left off. > > Details of unpack phase of installation or upgrade [...] > @@ -4540,31 +4595,29 @@ > > > > - For this reason packages in an installation run are usually > - all unpacked first and all configured later; thi

Bug#504880: Disambiguate "installed" for packages

nd and third reasons look to be more important, anyway. I would suggest removing the confusing sentence. It would be lovely to document the reasons for this detail of dpkg’s design somewhere, but it does not make the policy any more readable. > Jonathan Nieder writes: >>> - T

Bug#504880: Disambiguate "installed" for packages

Russ Allbery wrote: > Initial bootstrap, like udebs, feels to me like > something that's outside the intended scope of Policy. Note to self: beg Neil Williams to help edit a document based on multistrap. > Jonathan Nieder writes: >> * postrm does not get called until pre-

Bug#504880: Disambiguate "installed" for packages

Russ Allbery wrote: > Suppose that you have a package foo 1.0-1 with: > > Pre-Depends: bar > > and a package foo 2.0-1 that has no pre-dependencies. [...] > Now you run: > > dpkg -i foo_2.0-1.deb > > foo 2.0-1 has no pre-dependencies, so the pre-dependency check succeeds. > Installatio

Bug#504880: Disambiguate "installed" for packages

Steve Langasek wrote: > So I think it's better to say: > > This is a stronger restriction than Breaks, which just > prevents the package listed in the Breaks field from being > configured while the package with the Breaks field is present on > the system. > > Avoids refer

Bug#504880: Disambiguate "installed" for packages

Russ Allbery wrote: > I think we should hopefully be close to a final wording now. Indeed! All I have left are copy-edits (patch below). > +++ b/policy.sgml [...] > +The unpacked files may be > + partly from the new version or partly missing, so

Bug#504880: Disambiguate "installed" for packages

Russ Allbery wrote: [...] > (a common > situation when upgrading shared libraries and their > corresponding development packages) [...] > That moves the whole thing into a footnote and gives a more specific > example. Nice.

Bug#504880: mail-transport-agent (Re: Bug#504880: Disambiguate "installed" for packages)

Russ Allbery wrote: > Jonathan Nieder writes: >> Aside: is this advice right? Maybe we should be encouraging > >> Provides: mail-transport-agent >> Breaks: mail-transport-agent >> Replaces: mail-transport-agent > >> instead. [...] > newaliases progr

<    1   2   3   4   5   >