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)