Bug#777000: ITP: limereg -- Lightweight Image Registration. Commandline application for image registration (automatically aligning two images with similar content).
Thank you for giving so much details. Well, I'd be happy off course if
the package will be part of d-science and/or d-med.
I will apply your suggested naming scheme, maybe with one exception: I'd
prefer that the package named 'limereg' stands for the command line
tool, this makes it easy for users that don't know what a shared lib is,
and who only want to use the shell-utility named limereg. Then I could
for example add liblimereg-src as a source package, if that is ok
regarding the naming conventions.
There is already ppa in launchpad for Ubuntu (ppa:roelofberg/limereg)
that satisfies lintian. So if I understood everything correctly I will
do the following:
- Finish the library interface
- Check for quality (there is a limitation for square image dimensions
which I probably should eliminate before looking for a sponsor)
- Port the Ubuntu launchpad package to Debian
- Add further packages (lib, dev, dbg, src)
- Publish the packaging projects in branches of my original github
limereg project (right ?)
- Then ask for a sponsor by providing build and test instructions
Well, this will take a while. Thanks to everyone for supporting me so
excellently.
Regards,
Roelof
On 10.02.2015 19:24, Ghislain Vaillant wrote:
Added cc to debian-med.
I personally disagree with your statement on medical image
registration. I believe both fast and sophisticated registration tools
can live together. Your package would fit perfectly in d-science or
d-med, if not both.
Regarding your naming scheme, I have nothing against it. However, if
your project becomes a large library associated with an executable,
you might want to consider using limereg (source package name),
liblimereg (shared object), liblimereg-dev (symlinks + headers),
liblimereg-dbg (debug symbols) and liblimereg-tools or liblimereg-bin
(executables). Your call.
I would also suggest to finalize the separation between executable and
library first before doing the packaging.
Before actually finding a sponsor, you'd need to prepare the packaging
somewhere, in your personal or chosen debian team git repository for
instance, and make sure it is of sufficient quality for an upload
(using tools like Lintian). Then, you will file an RFS bug, which will
point prospective sponsors to the location of your packaging and give
them instructions on how to build and test the resulting binary packages.
Hope that helps.
Ghis
Reply to: