[k3b] [Bug 382754] K3b complains about missing cdrskin at start up

[Thomas Schmitt]

https://bugs.kde.org/show_bug.cgi?id=382754

--- Comment #18 from Thomas Schmitt <scdbackup at gmx.net> ---
Hi,

In
  https://github.com/KDE/k3b/blob/master/src/k3bsystemproblemdialog.cpp
it should not be recorded as CRITICAL if only one of cdrecord or cdrskin
is not usable.

A quick solution would be to report the messages preliminarily as
NON_CRITICAL and to check at the end of the burn program tests whether
both are missing.
If so, one would issue a CRITICAL message saying that no CD burn program
for cdrecord compatible options was found.

---------------------------------------------------------------------

In general the relation of the burn programs is wrongly represented in
this piece of code.

The programs overlap with their capabilites. If you just want to burn
a DVD-R with write type DAO, then growisofs, cdrecord, and cdrskin are
all three valid candidates for that.
If you want to burn CD XA or fast BD-RE multi-session, then two of
the three are not suitable.

So the severity evaluation should be delayed until it is clear how many of
the burn programs are available, and which tasks they can cover.

Consider something like this (properly adapted to K3B idiom, of course):

  struct burn_candidate {
    char *name;
    char *path;
    char *purpose;
    char *remarks[8];

    /* Problems, restrictions, or reasons for being unusable */
    int permission_problem;
    int does_not_exist;
    int is_outdated;
    int too_much_root;
    int not_enough_root;
    int would_need_atapi;
    ... maybe more ...

    /* Program capabilities */
    int does_cd_data;
    int does_cd_audio;
    int does_cd_other;
    int does_cd_multi_session;
    int does_cd_by_options;
    int does_cd_by_cue;
    int does_dvd;
    int does_dvd_multi_session;
    int does_bd;
    int does_bd_multi_session;
    int does_overwritable_multi_session;
    int does_fast_bdre;
    ... maybe more ...
  };

There would be an array of them with an element for each program that
may be used.
The tests would assess the problems and capabilities but not yet call
problems.append().
They would rather record the parameters needed for the messages.

When all assessment is done, one would next look which programs are
actually usable and which capabilities are covered by them.

If an important capapability is not covered by a usable program,
then this is should be reported as CRITICAL.
Further one could at this point choose the default programs for the
various tasks which demand the covered capabilities.

(Another burn backend K3B could encounter is "xorrecord", which is the
 cdrecord options emulation of xorriso. CD, DVD, BD. Data only. No audio.
 Based on libburn like cdrskin.)

---------------------------------------------------------------------

Before declaring a capability to be covered, the programmer will have
to verify that K3B can actually use that program for that task.
I.e. is K3B prepared to produce the necessary options ?
Can the program really do what the options demand ?

So, this proposal would cause substantial work and review of the
existing K3B code that controls the backend runs.


Have a nice day :)

Thomas

-- 
You are receiving this mail because:
You are the assignee for the bug.