High, high ...
* Andreas Pakulat <[EMAIL PROTECTED]> schrieb am [25.09.03 19:10]:
> > > 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.
>
> Also ich halte das eigentlich f�r gar nicht so verkehrt, wie cdrecord
> das macht. Ich bin auch letztens dr�ber gestolpert, und mein k3b l�uft
> auch mit dem script wunderbar.
welches? aus stable? Ich mu�te hier bei mir (stable+Backports) diesen
Kniff n�mlich auch machen, Ver. 0.9-2 von www.planet-moll.de woody/main.
>
> > > > 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.
>
> Der Maintainer von k3b hat definitiv sich das cdrecord Paket nicht
> genau angeguckt, sprich ist auf diese Eigenart des Debian cdrecord's
> nicht eingegangen. Das ist ein Bug im Debianpaket, unabh�ngig davon ob
> das jetzt sinnvoll ist mit dem Script oder nicht.
Hm, jetzt mu� ich aber auch mal ein paar Bemerkungen loslassen, aus
denen dann evtl. diese Riesen-Threads entstehen die ich eigentlich nicht
mag, mea culpa ;-)
Vielleicht erhellen die Antworten ja mein Verst�ndniss der Paketierung
und des Maintainens.
Wenn wir (wie beim OP) von einem stable debian ausgehen:
cdrecord (aus debian/stable) +
k3b (aus planet.moll.de stable)
-------------------------------
= beide abh�ngige Programme laufen stabil
dann aus unstable/sid mit dem o.a. cdrecord:
cdrecord (aus debian/unstable +
k3b (sagen wir aus planet.moll.de unstable
------------------------------------------
= beide abh�ngige Programme laufen stabil
dann wurde vom k3b-Maintainer in unstable diese ebenfalls nur in
unstable vorhandene cdrecord-Besonderheit ber�cksichtigt. Ob das nun in
unstable so ist (also funktioniert), kann ich nicht sagen. Aber
angenommen es w�re so, gegen wen sollten wir dann in unserem Fall einen
Bugreport schreiben? Jeder Maintainer kann doch von "seinem" Paket
sagen: wassollendaseh, es funktioniert doch in allen Releases.
Wenn ich aber jetzt mein stable mit Backports "verunreinige" (bitte die
Anf�hrungsstriche beachten, liebe Backporter(innen)!) und es
funktioniert mit dem Backport nicht, dann ist es IMHO ein Problem des
Backports.
Mein cdrecord ist von Adrian Bunk. Eigentlich m��te man ihm
dann doch sagen: hier, dein *Backport*, so wie du ihn aus unstable
packst hat dieses Problem mit dem k3b aus stable.
Wenn wie oben gesagt sowohl *reines* stable als auch unstable dieses
Problem nicht haben, dann m��te/k�nnte Adrian doch seinen Backport
anpassen. Z.B. eben das Skript weglassen und die Kernel-Abh�ngigkeit
z.B. mit symlinks und/oder /etc/alternatives l�sen. Halt so, das es mit
dem k3b aus stable harmoniert. Aber ob ein Backporter sich diese Arbeit
macht bzw. nach Debian Richtlinien �berhaupt machen darf, da� wei� ich
eben nicht.
Das waren so meine Gedanken warum ich eigentlich keinen Bugreport
schreiben m�chte. Antworten darauf gerne als PM, falls Antwortbedarf und
wenns vielleicht OT w�rde.
Gru�
Gerhard (nachdenkend ;-)
--
Haeufig gestellte Fragen und Antworten (FAQ):
http://www.de.debian.org/debian-user-german-FAQ/
Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED]
mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
