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 release notes file"
>> per the above definition (hand-written by the upstream maintainer,
>> targetted at end users). (Numbers in message #65 in this bug report.)
>>
>> Currently we (i.e. typically dh_installchangelogs) install this
>> Changes file as /usr/share/doc/package/changelog.gz. In the future
>> we'd need to install it as /usr/share/doc/package/NEWS.gz; or still
>> as changelog.gz if we can live with the deprecation (will this be
>> allowed "forever"?).
>
> Until we can remove the deprecation without making more than a handful
> of packages buggy. So, probably not for a long time.
I share gregor's discomfort: I don't think we've thought this through.
Can you summarize the goals for me? My understanding of the current
status is:
1. Installing all of upstream's release notes and source-level
changelogs is allowed. Many people want to install fewer.
2. Sometimes upstream doesn't provide adequate release notes.
3. Sometimes upstream provides sensible release notes, but not as part
of the source archive they distribute.
4. Some licenses require distributing source-level changelogs.
5. Policy 12.7, perhaps inspired in part by those licenses, describes
where the upstream changelog (without specifying which changelog is
meant) should be installed and requires that it be installed
there. It also has some requirements about format, compression
level, and so on.
6. No tools other than lint and humans' muscle memories rely on the
path it specifies.
Am I understanding correctly so far?
Given that background and my understanding of the goals, my proposal
would be
i. We come up with which changelogs we want to *require* shipping,
if any.
ii. We don't impose any requirement on filename other than that they
go in /usr/share/doc/<package>/.
iii. We come up with what format requirements we want to impose on
the changelogs, if any.
And we should take (2), (3), (4), and (6) into account when doing so.
Also, if my assumptions missed some pieces, I'd like to see them
clarified explicitly to avoid working at cross-purposes.
Thanks,
Jonathan
