[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: 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.


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.


Reply to: