Sean Whitton <spwhit...@spwhitton.name> writes: > Hello, > > On Sun 15 Dec 2024 at 10:52pm -08, Xiyue Deng wrote: > >> To look at it from complexity point of view, installing CHANGELOG.org as >> changelog requires the following minimum change: >> 1) Not included CHANGELOG.org in d/docs (which now only includes >> NEWS.org), >> 2) Override dh_installdocs to install CHANGELOG.org as changelog, >> while using a symlink from changelog to CHANGELOG.org requires: >> 1) Include CHANGELOG.org in d/docs, >> 2) Add linking to changelog in d/links, >> 3) Compress CHANGELOG.org by overriding dh_installdocs as it's not >> compressed by default and it's required for changelog.gz, >> 4) Add a lintian override for that what-I-think-is-a-false-positive >> tag. >> So the former wins here, and I have implemented it now in Salsa. > > Hmm, commit a2c1074 on salsa is otherwise okay but still does the > symlinking, did you forget to push? >
The symlink should have been removed at 927b478, and my local built
package does not seem to have any symlink to CHANGELOG.org anymore. Can
you pull and retry?
>> [ On the other hand, I think using CHANGELOG.org is becoming a common
>> practice in many ELPA packages and it should be considered a supported
>> format for changelog. I'll probably follow-up on this in another bug
>> to see if this would be acceptable, so that step 2-4 of the latter
>> won't be required. What would be a good place to file such a wishlist
>> bug? ]
>
> Again, file extensions don't matter.
> Writing CHANGELOG in Org format is indeed common; there is nothing wrong
> with installing it without its file extension. So, I don't think there
> is anywhere that has a bug.
>
IMHO treating Org mode documents as plain text is losing formatting
information. Similarly for markdown, Org mode files are plain text but
not quite, as there are formatting information that are used to add more
visual effect compared to plain text, and preserving them is good. The
policy supports NEWS.html and changelog.html. Why not also treat
CHANGELOG.{org,md} as a supported changelog format directly? This saves
maintainer time as well as preserve formatting information: if one
installs CHANGELOG.org as changelog and would like to preserve
formatting information, one may have to patch the file with `-*- mode:
org -*-' cookie for Emacs, or maybe other treatments for other
readers/editors, while CHANGELOG.org works OOTB and I doubt upstream
would accept patches adding the cookies because CHANGELOG.org is working
fine and changing the file name is the decision made by the Debian
maintainer. This puts Debian maintainer in a lose-lose position: having
to do extra work, and changes may not be accepted upstream.
>> Ack. It looks like policy 12.5 does say copyright information should be
>> verbatim, however as we can group the copyright holder spanning multiple
>> years, it becomes "not-verbatim" then. Oh well, guess nothing is
>> perfect.
>
> Yes, good point.
>
>>> You'll need a copy of the entire EPL-2.0, per Policy 12.5.
>>>
>>
>> Lintian warns about not including CC-BY-SA-4.0 full text but doesn't
>> warn about EPL-2.0. Anyway, I think including the full text is the safe
>> bet and this has been done.
>>
>> PTAL.
>
> Rather than relying on Lintian, just take a look under
> /usr/share/common-licenses and see what's there :)
>
I found /usr/share/common-licenses contains a very limited list of
DFSG-compatible licenses. Is there any proposal to extend the list so
that we don't have to include the full text for DFSG-compatible licenses
anymore?
> --
> Sean Whitton
--
Regards,
Xiyue Deng
signature.asc
Description: PGP signature
