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
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
