Re: CD als User Brennen
High, high ...
* Norbert Tretkowski <tretkowski@inittab.de> schrieb am [25.09.03 12:59]:
> * Gerhard Brauer <gerhard.brauer@web.de> wrote:
> > High, high ...
> > * Guenther Theilen <theilen@eqi.de> schrieb am [25.09.03 11:30]:
> > > /usr/bin# ls cdrecord* -l
> > > -rwsr-x--x 1 root cdrecord 142 18. Sep 22:37 cdrecord
> > > -rwxr-xr-x 1 root root 313544 18. Sep 22:37 cdrecord.mmap
> > > -rwxr-xr-x 1 root root 313576 18. Sep 22:37 cdrecord.shm
> >
> > Das Problem liegt am Backport. Darin ist cdrecord nur ein shell-script
> > (sieht man auch an der Dateigröße) welches je nach kernel-version
> > (2.0/2.2 oder 2.4) entweder cdrecord.shm oder cdrecord.nmap (die
> > eigentlichen Programme) aufruft.
>
> Das ist kein Problem am Backport, das sieht im unstable Package
> genauso aus.
Gut, ist eigentlich auch klar ;-)
Wie gesagt, IMHO ist diese Lösung nicht sehr sauber. Ich fände es besser
wenn da, wo cdrecord draufsteht auch cdrecord drin ist. Wenn ich je nach
meinem Kernel ein anderes Paket bräuchte, müßte ich mich selbst drum
kümmern, bzw. die Paketverwaltung.
> > Und genau damit, daß cdrecord in dem Backport ein Skript ist hat k3b
> > ein Problem.
>
> Dann sollte man einen Bugreport gegen k3b schreiben.
Ich werde keinen schreiben. Abgesehen davon, daß es mein erster wäre und
ich mich über das Verfahren informieren müßte, halte ich nicht das
k3b-Paket für den "Schuldigen". Wenn cdrecord in seiner zu erwarteten
Form vorliegt hat das k3b deb ja kein Problem. Und wenn der OP sagt "da
muß man erst mal drauf kommen" ist das eher ein Hinweis das ein Fehler
an der falschen Stelle gesucht wurde.
Ich würde vorschlagen, daß jemand der sich mit den Bugreports auskennt
und unstable verwendet, das mal ansieht und entscheidet.
Gruß
Gerhard
Reply to: