[PPL-devel] Re: RFC: packaging the PPL for RedHat and Debian

[Matthew Mundell]

>> On Debian some libraries come with a separate documentation package,
>> which is nice for situations where a smaller installation is required.
>> For example:
>> libctl-dev - Library for flexible control files, development version
>> libctl-doc - libctl documentation in HTML format
>> libcoin40 - high-level 3D graphics kit with Open Inventor and VRML97
>> support - runtime
>> libcoin40-dev - high-level 3D graphics devkit with Open Inventor and VRML97 support
>> libcoin40-doc - high-level 3D graphics kit with Open Inventor and VRML97 support
>> libcoin40-runtime - high-level 3D graphics kit - external data files
>> libcorelinux - Foundation Classes, Design Patterns, IPC and Threads
>> libcorelinux-dev - Foundation Classes, Design Patterns, IPC and Threads
>> libcorelinux-doc - Foundation Classes, Design Patterns, IPC and Threads
>> libcorelinux-examples - Foundation Classes, Design Patterns, IPC and Threads
>> So how about a libppl-doc?
>
> OK: let us see how this looks like.  How are the requirements of the GPL
> and of the GFDL satisfied then?  I guess they should go in all packages
> and not conflict with each other, right?

>From the policy manual:

    Packages distributed under the UCB BSD license, the Artistic license,
    the GNU GPL, and the GNU LGPL should refer to the files
    `/usr/share/common-licenses/BSD', `/usr/share/common-licenses/Artistic',
    `/usr/share/common-licenses/GPL', and `/usr/share/common-licenses/LGPL'
    respectively, rather than quoting them in the copyright file.

So for example in the Emacs 21 copyright file:

  GNU Emacs is Copyright (C) 1985, 1986, 1987, 1993, 1994, 1995, 1996,
  1997, 1998, 1999, 2000, 2001, 2002 Free Software Foundation, Inc.
  59 Temple Place, Suite 330 Boston, MA 02111-1307 USA and is covered
  under the terms of the GPL.  See the file
  /usr/share/common-licenses/GPL for more information.

  ...

The Emacs 21 copyright file also refers to the GFDL in the Info
directory, however the gcc-3.4 copyright file has:

    The documentation is licensed under the GNU Free Documentation
    License (v1.2), appended at the end of this file.

which seems more in order.


As far as duplicating the copyright and licence, the policy manual
includes:

    `/usr/share/doc/PACKAGE' may be a symbolic link to another directory in
    `/usr/share/doc' only if the two packages both come from the same
    source and the first package Depends on the second.  These rules are
    important because copyrights must be extractable by mechanical
    means.

So any PPL packages that depend on libppl can symlink to
/usr/share/doc/libppl.

>                                          I mean: the GPL must be part
> of the base package.  But it must be part also of the -dev package since
> the -dev package would seem to be independent from the base one (it contains
> the static library and the headers so it containts "the software" the same way
> the base package containing the shared library contains it).  Since we
> generate documentation from comments, the GFDL should also be part of the
> -dev package, right?

If the -dev package contains the documentation then yes, otherwise the
comments surely fall under the GPL.  A libppl-doc package would be
nice.  Perhaps this could include the interface docs, or the interface
packages could include their own docs, to keep the number of packages
down.

>                       But then, why not distribute also the other files:
> README, BUGS, CREDITS...

These are often included, as Michael wrote, in
/usr/share/doc/<package-name>, for example /doc/libdbi-perl contains:

    Changes.gz
    README.gz
    ToDo.gz
    changelog.Debian.gz
    changelog.gz
    copyright
    examples/

>                            If we want to have several packages these are
> all problems that must be solved.
>
> And, in all this separation: should we have both libppl-c and
> libppl-c-dev?
> One with the shared library and one with the static one?

That will mean many packages.  It should be alright to include the
interface development files in libppl-dev.

> Arent we going to end up with 20 or so packages for something
> that is not really that complicate such as the PPL?
> Let us think about this.