Arch Linux

This page reads like propaganda and does not seem to be very objective. Wasn't there a license problem because crecord was relicensed under CCDL?

Anyway, as this is a bugtracker: What problems do you have with current cdrkit package? "many problems" is nothing where we could start any bug hunting. ;-)

haven't seen cdrkit related bugs for along time. tend to close this. tpowa?

as far as i can tell there are no cdrkit related bugs reported mostly cause users are "forced" to use cli burning at some point. i have to admit that this method seem to be working.
though i havent been able to use any gtk related frontend. graveman, gnomebaker & brasero hang when trying to burn any kind of media without reporting any error at all.
i am guessing it is related to :
In all programs of the fork that send SCSI commands, you may be unable to access any of the CD/DVD/Blu-Ray drives at all if you are on Linux-2.6.8.1 or later. This is due to a missing workaround for the Linux kernel interface change that happened with Linux-2.6.8.1.

i havent tried k3b cause i dont want to download 250 mb just to burn media every once in a while.
also i havent tested if cdrtools actually solves this problem mostly cause of lack of a decent way to build it. the PKGBUILD in AUR is not working as expected.
last, the CDDL license, as the author states too IS an open source license http://www.opensource.org/licenses/cddl1.php

i also don't have reports about broken cdrkit package anywhere.
cdrtools were replaced because of license issues, that is the reason why many distribution throw it out of their shipping, as we did.

@tobias If the CDDL licence is the problem why we have a "/var/abs/core/base/licenses/cddl-1.0.txt"? And does this result about the problem with the licence coming from a jurist or perhaps from one of the people who have even had problems with the author of cdrecord?

Please don't see this as an attempt to start one of this needless flame wars. I ask this this only because my favorite is to package them both and let the user decide what is the best solution for themselves. This would help dolby too.

i add jan herere too perhaps he can remember it better, but i think it was illegal to compile something with an unfree license against kernel code.

@Grigorios: I've used graveman, gnomebaker & brasero (yep, all three of them) after cdrtools->cdrkit change and didn't notice any issue related to the change. I can only remember one report about k3b not liking symlink but that was fixed long time ago.

Here's official position of Debian: http://debburn.alioth.debian.org/FORK
IMHO the fork was made not just because of license change but also because the author of cdrtools thinks he's smarter than Linux kernel devs and Linux does things wrong etc. (there was more info on that topic on author's site in past).
Many of author's claims stated on his page are not true IMO.

Given the fact that distros are switching to cdrkit and its support is becoming better - there's no way back to cdrtools IMO.

@Romashka I respect your decision instead i haven't the same opinion about it because first i don't think anyone of the people behind the fork will have the same experience as schilly in the near future and second this fork is a disgrace for both sides.

So without any preconception i only suggest to let cdrtools and cdrkit coexist. But again i respect your mind and will stop here saying something.

Well, users still can use cdrtools (there is a package in AUR), but because cdrkit package provides/conflicts/replaces cdrtools (and this isn't going to change, I guess) they'll have to add IgnorePkg=cdrkit to pacman.conf (not sure if it works for provides/conflicts/replaces in pacman 3.0, but AFAIR it should work in pacman 3.1 which will be released very soon).

Ok, will have to agree with closing this, at least at this point, furthermore cause i dont have enough to backup the feature request. If anything worthwhile comes up soon i might reopen it. Thanks