https://bugs.kde.org/show_bug.cgi?id=372094
--- Comment #9 from Kevin Kofler <kevin.kof...@chello.at> ---
> but I want to ship still-maintaining && BUGFREE product to end-users.
I actually agree with you there. I really think we need to switch to libburnia.
You should just clearly communicate this to packagers when announcing the new
release, so we do not end up with things working poorly because wodim is
getting silently picked up due to outdated dependencies in the package.
You should also make sure that cdrskin is preferred over wodim even if wodim is
installed/symlinked as "cdrecord" (because updating K3b, even if we add a
Requires: cdrskin, is not magically going to make installed wodim packages go
away, we cannot really use Obsoletes or Conflicts to force it removed).
> Yes, I am editing libk3b/core/k3bdefaultexternalprograms.cpp for adding
> cdrskin to K3b::AbstractCdrtoolsProgram( QLatin1String( "cdrskin" ),
> QLatin1String("cdrecord") )
But that is only the easy part. You need to look at all the places where a
decision what burning program to prefer is made (or checks for "if burning
program == cdrecord, apply workaround foo"), make it prefer cdrskin for things
it is actually better at (remember that growisofs is unmaintained too, though
not as long as wodim, so cdrskin is the better choice if it works), disable
cdrecord-specific workarounds (start by looking at those workarounds already
disabled for wodim in the code you removed, but keep in mind that cdrskin is
not a fork of cdrecord as wodim is, so probably does not need ANY of the
cdrecord workarounds), etc.
I have seen a bunch of cdrecord workarounds while browsing K3b code in the
past, but unfortunately I do not remember the exact locations in the code. For
example, there is something that says that cdrecord fails at doing some things
for audio CDs in DAO mode, so cdrdao (another unmaintained tool (no news since
2009), that in addition also uses libraries from cdrtools/cdrkit, so also uses
the unmaintained wodim code) is used for those instead. (Searching for "cdrdao"
will probably find that particular one.) You really want to go through all the
burning code and check whether what it is doing still makes sense if cdrecord
is actually cdrskin.
--
You are receiving this mail because:
You are watching all bug changes.
