LWN: Comments on "cdrkit: Debian's fork of cdrtools"

cdrkit: Debian's fork of cdrtools

schily — Tue, 18 Aug 2009 08:55:17 +0000

>And another CMake convert :-)
>It seems CMake (http://www.cmake.org) is really starting to get
>momentum.

Cmake is no make program but just another cryptic way of doing
things the outdated way. When it was written first, the Schily makefile
system did already exist for 8 years.

Cmake is just an autoconf replacement - not a new program
like David Korn's "nmake". Cmake is no make program but a makefile
generator - you still need a working make program in order
to compile.....

Cmake creates extremely cryptic makefiles, that are hard to debug.

Cmake does not create a multi platform build environment,
so it is the same fetch - unpack - configure - compile - install - throw away idea as vanilla autoconf.

I see no advantage before the Schily makefile system.

>When I once built cdrtools myself, I also wondered why for every tool
>there was a special Schilling edition, like "smake" and others...

I wonder why some people wrote programs like "gmake" although smake
existed for years already...smake is highly portable (more portable
than gmake) and smake is definitely needed for some of the supported
platforms where gmake is too buggy.

BTW: I recommend to use the official and well maintained cdrtools
instead of the questionable fork that is unmaintained since more
than two years and that is based on an extremely outdated cdrtools
source.

cdrkit without cmake

nix — Tue, 02 Jun 2009 12:58:36 +0000

The build time for cmake is about five minutes :)

I suspect what's annoying people is that the syntax for cmake is quite
different from configure scripts, and it takes a good bit of manual
reading to figure out how to get a list of per-package compilation options
et al (cmake --help doesn't work for that as far as I can tell: you can
get lists of *all* properties or commands, but not only of those added byt
the thing you're trying to build. I have to resort to reading the
cmakefiles, which is not ideal!)

cdrkit without cmake

aleXXX — Fri, 29 May 2009 20:16:25 +0000

You can consider cmake a tool like make and the compiler, i.e. something
which should already be existing on the system.
On most systems this is now already the case.

On basically all desktop distros this is the case now, and more and more
other programs are converting to cmake. So maybe cdrkit is the first
program you are encountering now which uses cmake for your distro, but
there will be more in the future.

If you want to avoid the build time, you can also use the binary cmake
release which you can download here:
http://www.cmake.org/cmake/resources/software.html
It works on all Linux distributions (at least we don't know of any where
it doesn't).
This still adds size, but you can save the build time for cmake.

Alex

cdrkit without cmake

solardiz — Sun, 24 May 2009 04:59:12 +0000

We wanted to introduce cdrkit into Openwall GNU/*/Linux (Owl), a small distro for servers, and we finally did, but we found the build-time dependency on cmake very unfortunate. So we got rid of that dependency in our package, but this cost us time. For more info, see my posting to the Distributions list and our cdrkit package files, including README-cmakeless.

We find cdrkit's use of cmake unreasonable. cdrkit is relatively small (e.g., compared to cmake!) and it does not require "portability" to native development environments on non-Unix platforms (where the use of cmake could be an advantage). cdrkit is simply bloated by its use of cmake. :-(

cdrkit: Debian's fork of cdrtools

dvdeug — Thu, 14 Sep 2006 18:25:44 +0000

Users have a natural tendency to fork. Unfortunately, there seems to be some trouble getting the necessary pair of developers with the right attributes together to create and support the fork, and it take a lot of time and a lot of money to get a successful fork that doesn't depend on the initial pair of developers.

wodim?

jimparis — Tue, 12 Sep 2006 19:30:30 +0000

Frequently Asked Questions about cdrkit
=======================================

Q: What does "wodim" stand for?
A: It is not a forest troll and not a winner of the inpronounceability
contest. It was simply the next alternative to wom (Writes Optical Media)
which was unfortunately already used by other software products.

wodim?

xoddam — Mon, 11 Sep 2006 07:35:29 +0000

It could be Word of Deliverance Insititutional Ministries, Inc.

Or, just maybe, it's Write Optical Disc IMage (a guess...)

wodim?

kevinbsmith — Fri, 08 Sep 2006 04:04:13 +0000

This is good news. But what's a wodim? It appears to be the command line burning portion of cdrkit, but it would have been nice to have that explained. It would be fun to know the meaning behind the word, too. If it's an acronym, it would be easier to remember.

Why not dvdrtools?

cortana — Thu, 07 Sep 2006 10:46:24 +0000

Furthermore, dvdrtools forked from a version of cdrecord that was available under the GPL with the additional restriction that you may not alter or remove the FUD about Linux printed when cdrecord starts up. Debian currently have dvdrtools in non-free... I would have thought that this additional restriction makes the entire lot non-distributable, however.

cdrkit: Debian's fork of cdrtools - for non-debian

Zomb — Wed, 06 Sep 2006 01:22:37 +0000

Please send a note to the mailing list, maybe with the contents of your header file and the exact error messages. libcap support is a new feature, I am not sure dvdrtools support it whatsoever.

cdrkit: Debian's fork of cdrtools - for non-debian

nix — Tue, 05 Sep 2006 20:56:27 +0000

You need libcap.

cdrkit: Debian's fork of cdrtools - for non-debian

kenmoffat — Tue, 05 Sep 2006 19:45:19 +0000

Can we report non-debian bugs, and if so, where ? My systems run variants of LFS and they don't have sys/capability.h. I've got linux/capability.h, but that only contains CAP_SYS_RAWIO, not CAP_EFFECTIVE nor CAP_SET, so I can't compile cdrecord.c.

These systems are using linux-libc-headers-2.6.12.0 with glibc-2.3.6, or the CLFS linux-headers with glibc-2.4. Meanwhile, dvdrtools 'just works', even on multilib ppc64.

Why not dvdrtools?

Zomb — Tue, 05 Sep 2006 07:47:15 +0000

Because dvdrtools took off from an older version and has not received many updates/fixes since then but got some significant modifications to port it away from "Schilling-style". Previous Debian package already had dozens of fixes and extensions (many shared with other distros, after all), it would have been the hell porting them to dvdrtools and keeping the quality. Especially in the expected time period, Debian Stable has to be released by the end of the year.

So it was finally the better compromise.

And then there are good and active alternatives which are going to replace cdrtools in the (mid-term) future: libburn/libisofs based apps, libcdio seems quite usefull as well and there is http://littlesvr.ca/isomaster/ which also looks promising.

cdrkit: Debian's fork of cdrtools

asamardzic — Tue, 05 Sep 2006 06:32:18 +0000

After completing porting several small- and medium-scale projects from auto-tools to cmake, I can only confirm that (in my experience) cmake rocks indeed. Simple and consistent language made it possible for me to easily write feature testing macros, I was never able to figure out how to properly accomplish this with autoconf. The only slight problem is lack of complete documentation, I guess for projects with complicated setups one would have to order "Mastering CMake" book to get most from the tool. But this seems like fair game to me (mine copy of book is on its way), and on the other side cmake developers (and users too) are *very* responsive on cmake mailing list, so for lots of questions one could get the clarification this way.

Why not dvdrtools?

eru — Tue, 05 Sep 2006 05:13:37 +0000

I'm wondering why another fork. There was already dvdrtools.

CMake

ringerc — Tue, 05 Sep 2006 02:14:37 +0000

And rightly so - it's great. I work on a project that presently supports CMake and autohell in parallel (we're dropping autohell as soon as current CMake unstable gets a stable release) and the relative ease of maintainance is significant. Whenever we want to change anything significant or add any feature to the build system it goes from significant to amazing - CMake rocks.

cdrkit: Debian's fork of cdrtools

lovelace — Tue, 05 Sep 2006 01:38:39 +0000

Can I learn the basics in an hour or two?

Yes, absolutely. There was an article in Linux Magazine recently (disclaimer, free registration apparently required, and I'm the author of the article) about how to use CMake as well one here at LWN too. It's very simple to get started using it.

cdrkit: Debian's fork of cdrtools

finster — Mon, 04 Sep 2006 23:32:21 +0000

Yes! I look forward to testing cdrkit! Lets see if we can all chip in and assist the devs on this fork.

cdrkit: Debian's fork of cdrtools

moxfyre — Mon, 04 Sep 2006 23:02:40 +0000

I've never bothered to learn autotools fully since it's so complicated, and I can mostly just edit existing files to get what I want.

How steep is the learning curve on cmake? Can I learn the basics in an hour or two?

cdrkit: Debian's fork of cdrtools

aleXXX — Mon, 04 Sep 2006 20:35:50 +0000

And another CMake convert :-)
It seems CMake (http://www.cmake.org) is really starting to get
momentum.
When I once built cdrtools myself, I also wondered why for every tool
there was a special Schilling edition, like "smake" and others...

Alex

cdrkit: Debian's fork of cdrtools

erich — Mon, 04 Sep 2006 20:03:51 +0000

Why would you change the software? Change the user!

Instead of forking cdrecord, we could just fork the users!

cdrkit: Debian's fork of cdrtools

richo123 — Mon, 04 Sep 2006 18:27:07 +0000

Could not agree more! I have had a lot of problems with cd burning in Ubuntu and one was never sure because of Schilling's inpenetrable thicket where exactly the problem lay. His rants against linux scsi support used to really get on my nerves: Basic position was: use a proper unix like Sun or regress to a 2.4 kernel. Thanks (NOT) for the constructive input Herr Schilling! Time for a cleanout!

cdrkit: Debian's fork of cdrtools

moxfyre — Mon, 04 Sep 2006 18:01:48 +0000

Kudos to Debian!

I hope that this will result in a CD-burning package that is more responsive to the needs of Linux distros, and without all the chest-thumping egotistical BS that has surrounded cdrtools.