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)
