Bug#879863: Should all transitional packages really go in section "oldlibs"?
Package: developers-reference Severity: normal "Also, it is recommended to adjust its section to oldlibs and its priority to extra in order to ease deborphan's job." ( https://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-transition ) When I followed this recommendation I was asked not to modify the section to "oldlibs" because the package was not a library. Based on the developer's reference I thought that "oldlibs" was used as a special section for transitional packages. If this is not the case, please update the Developer's Reference. Additionally, please change "to extra" to "to optional". Thank you! Nicholas
Bug#879863: developer-reference conflicts with Policy on priority "extra" vs "optional"
Control: retitle -1 developer-reference conflicts with Policy on priority "extra" vs "optional" Control: severity -1 important Control: tags -1 patch Merge request filed here: https://salsa.debian.org/debian/developers-reference/merge_requests/1 Bumping priority because it contradicts a "should" directive in Policy §2.5. signature.asc Description: PGP signature
Bug#944325: please fix this unclear and obtuse phrasing in §7.8 (suggestion provided)
Package: debian-policy Version: 4.4.1.1 Severity: normal The full sentence in question is "This field should not be added solely for purposes other than satisfying license or DFSG requirements to provide full source code". "solely for purposes other than satisfying" is the problematic construction and should be rephrased for readability and clarity. I suggest replacing the whole sentence with "The purpose of this field is exclusively for cases where a package's license, or when DFSG requirements, necessitate its presence; Built-Using should not be used for any other purpose". This is much more clear and it flows nicely into the next sentence "In particular, it should not be added solely to enable finding packages that should be rebuilt against newer versions of their build dependencies." Regards, Nicholas
Bug#944325: please fix this unclear and obtuse phrasing in §7.8 (suggestion provided)
On Fri, Nov 08, 2019 at 10:53:31AM -0700, Sean Whitton wrote: > On Thu 07 Nov 2019 at 04:51PM -05, Nicholas D Steeves wrote: > > > I suggest replacing the whole sentence with "The purpose of this field > > is exclusively for cases where a package's license, or when DFSG > > requirements, necessitate its presence; Built-Using should not be used > > for any other purpose". This is much more clear and it flows > > nicely into the next sentence "In particular, it should not be added > > solely to enable finding packages that should be rebuilt against newer > > versions of their build dependencies." > > Thank you for this. I agree that the sentence is unnecessarily hard to > read. Perhaps you could propose a patch against policy.git. You're welcome :-) Done! https://salsa.debian.org/sten-guest/policy/merge_requests/2 Cheers, Nicholas signature.asc Description: PGP signature
Bug#944325: please fix this unclear and obtuse phrasing in §7.8 (suggestion provided)
Sean Whitton writes: > Hello, > > On Sun 17 Nov 2019 at 10:29AM -08, Russ Allbery wrote: > >> How about: >> >> [1] This field should only be used when there are license or DFSG >> requirements to retain the referenced source package. [2] It should not >> be added solely as a way to locate packages that need to be rebuilt >> against newer versions of their build dependencies. > > Thanks, I think this is good -- would be good to hear from Nicholas too > though. I agree this is clear for people who already understand what it signifies, but I don't think it's clear/accurate enough for a new contributor who is struggling to understand Policy, because "retain the referenced source package [singular]" seems to refer src:foo, if src:foo uses Built-Using, and this isn't the case. So: (3) The Built-Using field should exclusively be used to satisfy license or DFSG requirements, where those requirements stipulate that the specific versions of build-time dependencies must remain available in the Debian archive. With further consideration I think (2) should be cut and replaced, because it undercuts the clarity of this paragraph's premise. Eg: Clear (1||3) "should" premise, but if a tree falls in a forest and no one notices it fall then you can do this other thing (2) without anyone noticing. If a maintainer uses the field for (1), then it's a non-issue if they're also privately using it as a heuristic for (2). Thus I don't think we need to say anything about the (2), because it's confusing for people who don't already understand the discussed concepts. Rather than (2), I think it would be better to refer to the general case of how to use foo.buildinfo (or tooling that leverages buildinfo, or some other method) to identify packages that need to be rebuilt. Sorry for the delay replying! Regards, Nicholas signature.asc Description: PGP signature
Bug#944325: please fix this unclear and obtuse phrasing in §7.8 (suggestion provided)
Hi Sean, Sean Whitton writes: > Hello Nicholas, > > I am not sure what is going on with your (1), (2) and (3). Perhaps you > could propose your change in the form of a patch. > Those numbers refer to annotations in the quoted portion. IIRC you're also using notmuch mode, so [ x more citation lines. Click/Enter to show. ] Needs to be activated to make them visible. At any rate, I've submitted an update MR here (see previous email for extended rationale): https://salsa.debian.org/sten-guest/policy/merge_requests/3 Cheers, Nicholas signature.asc Description: PGP signature
Bug#905453: debian-policy: Policy does not include a section on NEWS.Debian files
On Sun, Aug 05, 2018 at 12:02:11AM -0700, Jonathan Nieder wrote: > 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? > The section in Developer's reference looks good to me, and the only nitpits I have with are a couple of grammar issues. If no one has any objections I'd be happy to copy move the section, properly attribute its author, resolve these issues. One thing I'm not sure about is what Policy section it would go in. Would it be appended to §4 as §4.18, or something else? Best, Nicholas signature.asc Description: PGP signature
Bug#685506: debian-policy: Please add field Files-Excluded to machine readable copyright files definition
Hi, Sean Whitton writes: > Hello, > > On Sun 25 Oct 2020 at 09:40PM -04, Joe Nahmias wrote: > >> Is this truly the case that all that's needed is a new patch? Can we get >> an official ACK from one of the policy editors? I'd be happy to re-write >> the original patch to apply against HEAD if that's all that is required. > > Well, it would need seconding, but otherwise, ACK. > > Thank you for your interest. > Gentle ping to Policy editors for that seconding :-) It would be really nice to move this info from tribal knowledge to documentation. Best, Nicholas signature.asc Description: PGP signature
Bug#998165: debian-policy: document and allow Description in the source paragraph
Hi! Reply follows inline, Mattia Rizzolo writes: > On Mon, Dec 27, 2021 at 01:20:14PM -0700, Sean Whitton wrote: >> In that case, returning to Mattia's patch, it is probably not correct to >> say that the source Description is relevant for all binary packages, >> because perhaps the substvar is used for some but not all of them? > > Mh, we probably we'll need Guillem to confirm/deny this, but here I > really really was trying to not even mention on the substvar thing. > That to me feels like an implementation detail on how to fill a binary > package Description (that can already be accomplished in several other > way). > In my mind I was mostly focusing on being able to provide a > **description for the source package** (that is, then, relevant to > everything that source package builds); said description being picked up > by a substvar and used again later on is more like a nicety that comes > after describing the source first. > The following is only Informational level, but the existence of Lintian's "duplicate-long-description" tag suggests that producing duplicate bin:Descriptions in bin:libfoo and bin:foo packages is not ideal, thus a straight copy from src:Description is not ideal. I'm not sure what the best way to solve this is, but substvar looks like a good solution. Alternatively, simply appending "\n\n$binary_pkg\n" to the src:Description when generating the bin:pkg Descriptions would do the trick. Maybe there's an even better way? > Should I perhaps express my intention differently? For example: > > |+When used in a source control file in the general paragraph (i.e., the first > |+one, for the source package), the text in this field is used to describe the > |+source package itself, and consequently all of the binary packages > |+built from itself. > This appears to conflict with the "duplicate-long-description" tag. Of course, Lintian isn't Policy, but I hope most will agree that it's worth considering this precedent in some way. Regards, Nicholas signature.asc Description: PGP signature
