Re: RFS: gcc-4.5-doc-non-dfsg
On Sat, Jan 21, 2012 at 11:21 AM, Adam Borowski <kilobyte@angband.pl> wrote:
> On Sat, Jan 21, 2012 at 05:09:35PM +0100, Jakub Wilk wrote:
>> * Samuel Bronson <naesten@gmail.com>, 2012-01-21, 00:38:
>> >* Package name : gcc-4.5-doc-non-dfsg
>>
>> Does "non-dfsg" really need to be a part of source package name?
>> What if FSF decides to free the documentation one day?
>
> Then this source package will disappear, and its binary will be built from
> pristine gcc sources.
And it would save a lot of trouble, too: the gcc packaging can already
build the docs, and on Ubuntu it actually does. In fact, in some ways
it might be better to somehow arrange to use that same packaging with
the pristine upstream tarballs to build the documentation packages.
This would hopefully reduce the effort spent on these -doc-non-dfsg
source packages to almost nothing, at the cost of some disk space and
perhaps a lot of unnecessary compilation (if upstream's build system
can't be coaxed into building the docs without compiling loads of
libraries).
As for the name, a quick look at the changelog will show that I
obtained it by replacing "4.4" with "4.5" in the name of the source
package that mine is based on.
> It contains parts that have been removed from gcc-4.5, all of them are
> non-free due to GFDL issues.
Well, maybe not *quite* all: my understanding is that gpl.7 and gfdl.7
are, in fact, free (not sure about fsf-funding.7). According to the
description of the gcc-doc-base binary package, we ship these to
comply with the license(s) of the other manpages.
Though, now that I've opened these three files in Emacs, I see that
they were generated with pod2man, and aren't actually sources. Ought I
to add rules to rebuild them from source in debian/Makefile? A look at
upstream's gcc/Makefile.in shows that they're built using texi2pod
followed by pod2man (using explicit rules for the texi2pod step due to
mismatched filenames). Though, there isn't really any practical reason
to do this: we aren't allowed to modify the text of those documents
anyway. (What we *are* permitted to do is to use (parts of) the
license texts in licenses of our own.)
Reply to: