k3b: separate wrapper derivation to easily override cdrtools (e.g. with cdrkit) #44268
Conversation
|
In my experience cdrtools is a superior tool to cdrkit for writing DVDs and CDs, so I would like to not see this merged. In fact, I think cdrkit wasted a couple of CDs and DVDs whereas cdrtools has never failed. Having both on PATH is a reasonable option (disk space is cheap, wasted time on a broken CD is not). If it uses cdrkit for Blueray only (if that's the only option) then that's fine, but let's not throw out a program that actually works (cdrtools). |
|
@coretemp That's interesting .. do you run cdrtools as root or at least with special capabilities (k3b as root, or cdrecord as setuid or modified with setcap)? Given your observation, I see three possible scenarios here:
I hesitate to add both cdrtools and cdrkit to the PATH: k3b lets the user decide which to use, but it stores this choice as an absolute path (/nix/store/123abc..-cdrtools/bin/cdrecord) in its configuration file. Therefore I expect k3b to get confused if those paths change due to an update. I'm wondering if it makes sense to create three k3b derivations for the scenarios above, or one without a wrapper that can easily be extended with a wrapper containing cdrtools or cdrkit or maybe nothing so that k3b finds wrappers in /run/wrappers/bin . Would that be a good idea? |
The k3b package uses a wrapper script to inject binaries
that are called by k3b and do the actual work into PATH.
Most of those binaries are beyond reproach.
There are, however, legitimate reasons to replace
cdrtools with cdrkit, or with nothing at all to encourage
k3b to use suid wrappers from the surrounding PATH.
To ease the use of such cdrtools replacements,
this commit moves the wrapper script into its
own derivation (created with symlinkJoin).
To use k3b with cdrkit, this line in configuration.nix
suffices and won't trigger a rebuild of k3b itself:
> environment.systemPackages = with pkgs; [ k3b.override { cdrtools = cdrkit; } ];
Using "null" for cdrtools is possible and will skip
the addition of cdrtools to PATH in the wrapper script.
This commit is motivated by
NixOS#19154 .
Yarny0
changed the title
|
I'm closing this one for now as the approach seems to be fruitless. As soon as I find some spare time I will try to propose a solution that encompasses all scenarios (that I know of). |
This commit replaces the dependency on
cdrtools with a dependency on cdrkit.
The change affects the PATH seen by k3b (set by a wrapper);
k3b finds the required binaries by itself.
Advantage of cdrkit:
Based on experiment (by committer),
it permits writing optical media without superuser privileges.
Advantage of cdrtools:
It seems well supported and allows writing blu-ray media
(at least that's what the k3b feature list claims).
This commit should fix
#19154 .
Motivation for this change
Writing optical media should work without superuser privileges.
Things done
sandboxinnix.confon non-NixOS)nix-shell -p nox --run "nox-review wip"./result/bin/): k3b fails with same error that also occurs without this commit, which is probably due to NixOS 18.03 environment:qt.qpa.plugin: Could not find the Qt platform plugin "xcb" in ""nix path-info -Sbefore and after)cc @Phreedom @svanderburg