On Wed, Dec 31, 2008 at 11:58:07PM +0200, Stefanos Harhalakis wrote:
> I believe that there are some arguments for including it in debian too:
> a) It is not integrated. It just integrates with the desktop environment. It 
> is a single executable binary that interracts with hal and dbus. After 
> opening a luks device, the device is handled by KDE as a normal mapper 
> device. It should work for gnome and KDE4 too
> b) From what I've seen, up to KDE 4.2, there is no good support for crypted 
> volumes (correct me me if I'm wrong). This little program fills the gap.
> c) It's the only way (?) to have easily accessible encrypted removable 
> devices.
> d) As you said, "sime". Why not have this available for that time?
> e) It is a program that exists today and solves a "today's" problem. Isn't it 
> better to have this available for the next year (or more), until it is ported 
> to KDE4 or KDE4 gets support for encrypted devices?
> f) Are there any drawbaks for including this in debian?
> g) Isn't this what happens with all other packages? AFAIK, the KDE3->KDE4 
> transition of programs is not a debian's issue but the program's developers. 
> Why not distribute this with debian too?
> Anyway, without beeing a DD, as a debian user, I'd like to have this program 
> available as a package. 
> So, to conclude, just take a moment to reply with at least a simple go-on or 
> don't-go-on. I won't argue any more.

You are free to package it and ask people to sponsor it. Nobody can forbid you
of uploading a proper package to Debian if you find a sponsor, but think in the 
work that this will carry to the distro for maybe little gain. Your package
will be some time in unstable, yeah, but its final target won't be being in a
debian release given that squeeze (next release after lenny) will have KDE 4.

Even if some of the work is never lost time, specially if you improve your 
packaging skills, introducing a new package in the archive is also work for 
people in the distro like ftpmaster accepting/removing it, another developers
coordinating transitions, buildd maintainers taking care of the builds across
all the archs, kde team taking care of the reverse build depends, people who
packages stuff in what your package relies taking care too of reverse build

If you have more questions ask. I hope all the above stuff helps you to
understand what is the right thing to do here.



Reply via email to