Re: More packages: PVRG & dicom3tools
On Sun, 14 Dec 2008, Mathieu Malaterre wrote:
Sorry for being dense, but what does that have to do with medicine or
biology?
It is a precondition for some medical imaging application - but well,
not really medicine specific if you ignore the fact that nobody is
missing this feature outside the medical imaging world. I guess people
tend to use PNG format if they need lossless image compression.
I guess you are right it could be a more general package. Long story
short, no one really care about yet another JPEG implementation, right
?
I would love to care sponsoring-wise for your package ... ;-)
Full ref:
http://apps.sourceforge.net/mediawiki/jpeg/index.php?title=Pvrg
Is this targetted at collab-maint?
I am fine with all options.
I'm quite relaxed in which repo a package might end up. The VCS
tags - if properly set - will inform every user about the location
of the packaging stuff. I'm in big favour of using a mailing list
*which* *cares* as the maintainer address. So if the package would
be moved to collab-maint we should at least put
debian-med-packaging@lists.alioth.debian.org as the maintainer (and
Mathieu and the sponsor who uploads the package as Uploaders) to
make sure that problems in the package go to the location where
somebody is able to care (for instance if Mathieu is on vacation or
something like that). In principle I have no problem to also move
preconditions for medical packages in Debian Med SVN but I have
no strong opinion about this. I have only a strong opinion on
not leaving packages bit rot in a anonymous collab-maint trash bin.
Also, why is the debian
directory apparently in the upstream subversion repository?
Why not ? I am doing it with the gdcm project and debian-med people
are fine with it, since the official tarball do not contains the
debian/* files (there is a cmake rule to skip this particular dir).
I am not comfortable with the debian process, so for the small
organization I am working for, we use directly the svn repository to
build the debian package and install it on remote station. I guess
when the official gdcm/debian package will be out, this would not make
much sense, but meanwhile, I really would like to keep it this way.
Well, Michael is refering to the fact that we really like to have
an upstream source tarball without a debian directory. I tried to
explain the drawbacks in the past for gdcm. I also see your point
that you like to provide an intermediate solution for you users as
long there is no official Debian package (which lasts longer than
I wanted it to last - but that's life). My suggestion would be to
keep on maintaining a debian directory in your upstream SVN but
publish a source tarball without this. If you don't think this
is acceptable I would recommend to use a orig.tar.gz for official
tarball which just removes the debian directory in the get-orig-source
target.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: