Re: Debian packaging for FreeMED and REMITT

[Andreas Tille <tillea@rki.de>]

On Wed, 27 Oct 2004, Jeff wrote:

> It was more of a complete rewrite than a successor to FreeB. The idea
> is basically the same (split off the billing engine), but the
> architecture is far more advanced.
Sounds great to me.  So I guess FreeB would be more or less replace
FreeB, right?

> >     2. I did some patches to his packaging stuff which are available at
> >
> >             http://people.debian.org/~tille/packages/freeb/
> >
> >        in August this year but Jeff did not reacted until today what he
> >        thinks about these patches and whether we should do the upload.
> >        (I would love to hear his OK even if it is free software but it
> >         is kind of normal politeness to ask for it.)
>
> That's fine with me. I was maintaining the FreeB packages, and just
> making minor changes to deal with the release stuff. REMITT's debian
> packages are built in the same sort of way ... I'm sure there are
> gross inefficiencies, though.
I'm more than willing to have also a look at REMITT.  I hope that I will
find some time next week.  Do you have any URL to the source packages of
the Debian package?

> >    1. djview:
> >
> >       ~> apt-cache policy djview
> >       djview:
> >        Installed: (none)
> >        Candidate: 3.5.12-5
> >        Version Table:
> >           3.5.12-5 0
> >          499 http://debian.tu-bs.de testing/main Packages
> >           50 http://debian.tu-bs.de unstable/main Packages
> >
> >        --> This is available in Debian and can be removed once Sarge is out
>
> Agreed. It was simply a backport of the djvulibre packages, which
> FreeMED relies on for image handling, and which did not exist in *any*
> form in Debian stable.
>
> I have since decided to recommend the use of Debian testing due to the
> more up-to-date yet fairly stable nature of the packages.
I guess this is a reasonable decision.  I'm perfectly convinced that
you should use Debian stable in a production environment.  But if we
talk about development or even reasonable sized test installations
Debian testing is the distribution of choice.  I'm running it on
nearly all machines (with the exceptions of servers which are available
from internet.

> >     4. libbit-vector-perl
> >        This is not yet contained in Debian.  Somebody should step in here
> >        and file a RFP bug to wnpp in the way it is described at
> >
> >               http://www.debian.org/devel/wnpp/#l1
> >
> >        This should include a link to the packages at apt.freemedsoftware.com.
> >        If no developer steps in ask for anybody who might sponsor your package
> >        to get it propagated to the official Debian mirror.  This would save the
> >        FreeMed people from the task to provide it from their private mirror and
> >        get the package under control of the Bug Tracking System.
> >
> >     6. php4-pear-modules
> >        I would proceed like described at item 4. ...
>
> I still don't know what to do about these. There is no way to get
> addon PEAR modules other than installing them from tarball, and this
> schema seemed decent.
Well, somebody has to *ask* for the modules in the way it is described
at the URL above.  If the interest in these modules is big enough they
will be moved to the official mirror.  Perhaps we just sponsor the packages
you prepared.  But this needs more man power than my own.

> There are a few other packages available in the repository
> (naturaldocs, libwx-perl, xconfigurator, et cetera), which I have
> needed for various projects, and have made available through the
> repository.
As I said, asking for these packages (by filing RFP bugs) is the
way to go if you want to reach the goal that you get rid of the
boring job to prepare private packages for certain software.  Pointing
people to the work you did in this RFP bug might speed things up.

Kind regards

           Andreas.