Ok following the release 1 from yesterday, I released a version 2 of unieject, working fine on FreeBSD and Linux, with a complete manpage and a cleaner API. It also has cdspeed support and a non-working cdslot option.
This version is now in portage (just ~amd64… i still think that an x86 arch team is needed, but that is), with its dependency txt2man.
To work on FreeBSD it needs a patch in libcdio code, so I just added it as 0.75-r1, that patch is not needed on Linux. I’ve submitted it to libcdio-devel mailing list and to FreeBSD’s ports maintainer if he wants to update the ports version of libcdio.
But there’s a question unanswered for now: “Why someone should think to use unieject under Linux instead of eject?”
Good question, and I don’t really have a clear and safe answer for it.. i can just say a couple of things about this. The first one is that eject is not exactly “maintained” (and imho is also a bit overwhelmed, I’m still wondering why it should set cdrom speed and so on), the second one is that it uses system() to call umount when it tries to unmount a device.. I don’t really like that, unieject uses library functions to do the unmount job so it’s, imho, safer.
Another reason is simply that it’s simple to have one single portable version of eject than many different ones, but that’s just a gentoo specific requirement (no other distribution is cross-os).
Well now I really need to start adding gettext support to unieject and force kito to help me with unieject on OSX 🙂
