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

Re: Problems with source-orphan documents in dialign-t



On Mon, 19 Nov 2007, Charles Plessy wrote:

Since dialign-t is a scientific software, I would like to avoid messing
with the upstream tarball

Uhm, why that?  There are several reasons to touch a tarball and there
is no problem to do this if you document it right.  The best documentation
is a get-orig-source target in debian/rules accompanied by giving the
reasons for touching the original tarball in README.Debian.  Moreover
I see no difference between scientific software and non-scientific software
in this respect.

so that people who want version 2.2 can use
"2.2" without wondering wether "2.2+dfsg" means that the algorith was
changed.

A user who is paranoid has to verify in any case that you did not changed
the source that is provided by upstream.  If the reason for touching and
renaming the tarball is clearly given, there is no problem with this.  There
is not even a reason to name the tarball differently if you change something.
The '+dfsg' is kind of a reasonable convention but not mandatory (IMHO).

If the outcome of the discussion on -devel were negative, would
somebody accept to upload dialign-t in "non-free", with a minor
modification of the package description, such as "You can use, modify
and redistribute dialign-t under the terms of the GNU LGPL version 2.1
or higher ; this package is in the non-free section because the LaTeX
sources of its documentation are missing. A XML replacement is provided
for your convenience".

I'd strongly vote against putting a package under non-free just because of
formal reasons like:
  - Upstream has no time to answer the request of providing missing
    pieces of source for the docs
  - Maintainer hesitates to touch upstream tarball even if there is
    fully free replacement available
  - Code is free but some additional chunks of data are not (in this
    case we should split the source into '+dfsg' and '+non-free'
    but our current case is different, because there is a replacement).

Did you forewarded the XML to the author (perhaps he likes to add this
to the upstream tarball)?

Thanks for working that quickly on a replacement doc

        Andreas.

--
http://fam-tille.de



Reply to: