[Debian-med-packaging] Bug#689951: Package appears to be non-free

[Emmanuel Promayon]

Hi Andreas,

> If you can remove it upstream this would probably the bes solution.
> Please note the following:  The Debian Release team does not accept
> new upstream versions for Wheezy in general.  So if the change should
> be successfull for propagation to Wheezy please make prfectly sure
> that this change is the only one compared to the tarball currently in
> testing.  So you culd do something like
>
> camitk-3.0.2.1.tar.gz
>
> and mention in the upstream changelog something like
>
> - Just removed parts of code which are not DFSG free (no other code
> changes
>
> In the debian/changelog we could refer to the fact mentioned in your
> upstream changelog to convince the release team that we do not
> attempt to sneak in new upstream code.  Otherwise we would need to
> "backport" the changes to the version inside Debian. (In case my
> advise was not clear enough feel free to ask for further
> clarification.)

> May be I was not fully clear.  If we drop the tetgen dependency
> completely (and if I understood correctly the plugin in queston needs
> to be dropped / deactivated as well) then and only than camitk can
> remain in Debian main.  If there is some dependency from any non-free
> component (be it tetgen or whatever) the package needs to be moved
> from main to contrib which is something I would like to avoid. So the
> action to let camitk remain in main is the following:
>
> 1. Remove tetgen fom the upstream tarball (may be also cut the
> plugin in question as well if it does not make any sense without
> tetgen). 2. Build a camitk package targeting at main from this source
> tarball.

Would it not be possible/preferable/easier to convince the release team
to remove the non-free code as a debian package patch?
If not, as at the moment the upstream changelog is not very visible,
should I add a specific news on the web page to explain what happened
between camitk-3.0.2.1.tar.gz and camitk-3.0.2.tar.gz?

> To gain full functionality we could gain (for Wheezy+1) optionally
> with
>
> 3. Create another source tarball camitk-plugins (or
> camitk-plugins-non-dfsg or whatever name). 4. Build an according
> Debian package from this plugins tarball linking with Debian packaged
> tetgen targeting at contrib and recommending camitk from main 5. You
> can Suggests camitk-plugins in the camitk package (but not
> Recommends, which is only allowed inside main)

That sounds like the perfect idea.

>> For #690830 there is a patch proposal and there is also a another
>> way that I would like to try first (that will probably have better
>> compiler specific/multi-arch support).
>
> This could be done if you are pretty sure about this and the change
> is obviosely simple and straight to get accepted by the release
> team. While it is a really good thing to fix this bug we need to make
>  pretty sure it will not introduce new problems (which is the sense
> of the freeze process).
>
> For the time line:  I think doing step 1.+2. from above until end of
> October is fine.  Everything else has time because it does not affect
> the current release.  Is this doable for you?
Yes, I think there is no problem to do that between now and the end of 
the month.

-- 
Emmanuel Promayon
UJF-Grenoble 1, CNRS, TIMC-IMAG UMR 5525 (équipe GMCAO)
Institut de l'Ingénierie de l'Information de Santé
Faculté de Médecine - 38706 La Tronche cedex - France
Tel. +33/0 456 52 00 03 - Fax. +33/0 456 52 00 55 - B7