[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#965363: RFS: opencpn/5.2.0+dfsg-1 [RC] -- Open Source Chartplotter and Marine GPS Navigation Software



On Thu, Sep 10, 2020 at 05:12:34AM -0400, The Wanderer wrote:
> > https://www.debian.org/doc/debian-policy/ch-source.html#debian-changelog-debian-changelog
> > for some better/more accurate wording in the Policy)
> 
> I'm not sure I read that section as meaning that. Could you point more
> specifically to the exact wording there which you understand as
> reflecting this rule?

Policy says:
"Changes _in_ the Debian version of the package should be briefly explained in
this file." (emphasis mine)

(I'm positive that project at large interprets that as like I do. People told
me it too, when I was learning packaging. The manpage for debian/changelog seems
to support this futher.)

Though note that is a "should" requirement only, so this would a "normal bug",
not "RC."

> Regardless, I'm fairly sure there are exceptions to this in practice.
> For example, if a new upstream release includes a change which closes an
> open Debian bug report

A "New upstream version" packaging is a change to the Debian packaging
(regardless if it closes a bug or not) If it happens to close a Debian bug, it
is recorded like all other bugs.

> or fixes a particular CVE, a notation in the
> changelog recording that fact seems to be de rigueur, and in fact as I
> understand matters the tooling recognizes and parses notes such as
> "Closes: #123456" or "CVE-1000-123-1234" to auto-close the given bug
> report or to mark a newly-packaged version as unaffected by the given
> CVE.

CVEs are a special expection anyway, as it is basically the only instance where
even rewriting history* is permitted in d/changelog.

(* changeing old changelog entries)
 
> For that matter, look at the Linux kernel packages
> (linux-image-VERSION-ARCH, among others). They don't seem to ship a
> changelog.Debian.gz, but the changelog.gz which they do ship seems to be
> in Debian changelog form and list Debian package versions, and is
> reported by apt-listchanges at upgrade time; in that file, each new
> Debian version tends to contain a "New upstream stable update" entry,
> which is then followed by a kernel changelog URL and a lengthy, detailed
> listing of changes (apparently nearly commit-level) taken from that
> upstream changelog.
> 
> I'm not sure this is best practice, or that it would be a good thing for
> other packages to be doing en masse - but it's a large-scale example of
> including upstream changes in debian/changelog, and it certainly doesn't
> seem to be an unacceptable violation if something as core as the kernel
> packages have been doing it for so long and are still going that way.

You should discuss that with the kernel package maintainers.

Policy says that "Every _source_ package must include the Debian changelog
file, debian/changelog.", and they do:
https://tracker.debian.org/media/packages/l/linux/changelog-5.8.7-1

For _binary_ package the relveant policy section is §12.7 and the filename is
/usr/share/doc/package/changelog.Debian.gz, so technically you are seeing the
upstream changelog.  (I guess this is discussion becoming off topic for this
RFS, so I leave it here…;)

-- 
tobi


Reply to: