NMUs sind soweit ich weiß nur für den Fall gedacht, dass der Maintainer nicht erreichbar ist oder bei kritischen Problemen zu lange nicht reagiert. Der Maintainer scheint hier aber durchaus aktiv zu sein, er möchte nur einfach nicht das Paket aktualisieren.
Warum kann man das Paket, welches ja open-source ist, nicht unter neuem Namen forken, auf den neuesten Stand bringen und dann in Debian nutzen? Dann koennte der alte Paketbetreuer machen was er will und die Community bekommt ein funktionierendes Paket.
Das kommt darauf an, wenn das Paket eine Library ist, dann müssten ja auch alle Programme gepatcht werden, die neue Library zu verwenden. Und Upstream wird man solche Patches niemals bekommen, wenn das ein Debian-internes Problem ist und in anderen Distros das Paket normal gepflegt wird.
Maintainern das Paket wegzunehmen, wenn sich diese nicht mehr darum kümmern, halte ich für die einzig sinnvolle Lösung. Außerdem sollte es generell mehr als einen Maintainer pro Paket geben, denn diese könnte ja kurzfristig nicht erreichbar sein (z.B. Krankheit).
Debian existiert seit 1993. Die Tatsache, dass dieses Problem bisher noch nie auftauchte spricht dafür, dass die getroffenen Regelungen funktionieren. Wahrscheinlich hat man bisher immer eine einvernehmliche Lösung gefunden. Die persönliche Paketbetreuung ist auch ein Garant für Verantwortung, Kontinuität und Qualität. Vielleicht ist es besser wenn das TC beim Paket GNU Global eine Ausnahmescheidung trifft. Eine unsensible Diskussion um das Maintainment legt die Axt an das Selbstverständnis aller Mitwirkenden und hat die Potenz das ganze Debian Projekt zu gefährden. Der Wunsch nach Teamarbeit sollte von den Maintainern selbst kommen.
Das Problem ist auch früher schon zig-Mal aufgetaucht, ein sehr bekanntes Beispiel ist Wine 1.0.1 in der Squeeze-Ära, das so als Wine 1.0.1 auch bereits in der vorgehenden Lenny-Zeit angeboten wurde. Das bedeutet, dass Debian Stable-Nutzer zwei Releases lang nur Wine 1.0.1 zur Verfügung hatten.
naja, selbst wenn es eine lib wäre kann der Fork bei der Installation ja einen symlink bereitstellen. Ging bei wodim ja auch (welches ja in der Folge selbst aus anderen Gründen praktisch un-maintained ist ...).
Man müsste halt zumindest Pakete, die nicht maintained sind, radikal aus der Distribution entfernen. Das würde natürlich in Einzelfällen sehr schmerzen, nur wäre Debian dadurch insgesamt sicherer.
Cdrkit samt wodim und genisomage ist so ein Fall. Wenn dann z.B. der Fileroller-Maintainer dann weiterhin auf einer Genisoimage-Abhängigkeit bestünde, dann müsste auch Fileroller entfernt werden, genauso wie Brasero und K3b.
Aktuell ignoriert so gut wie jede Distribution dieses Cdrkit-Problem: Cdrkit ist EOL, unmaintained, es findet keinerlei Weiterentwicklung statt. Dann lieber Xfburn und Libburnia.
Ich installiere ja ein aktuelles cdrecord einfach nach. Allerdings ist das CD Brennen an sich auch bald EOL Und BluRays sind für mich irgendwie nie ganz in den Distributionen angekommen ... wie geht den libburnia mit denen um, ist das akzeptabel?
Weil es Namenskonvetionen gibt und die vom Upstream Projekt abhängen. Das wiederum würde zur folge haben, dass Debian ein stable release (welches die Anforderungen an gleichbleibende Abhängigkeiten über die ganze Laufzeit, sowie keine neuen Pakete, hat) kaputt machen würde.
Also ja, natürlich wäre es möglich aber das wäre keine Lösung und würde nur zur Verwilderung des Paketjungles fühlen.
____
Das Paket jemanden weg nehmen sehe ich auch nicht als Lösung an. Bestünde die Chance, dass mein von mir gepflegtes Paket mir entrissen wird, weil ich z.B. im Krankenhaus liege oder länger Urlaub mache, würde ich kein Betreuer sein wollen. Ebenso ist es wenn ich mit der Entscheidung einen Patch zu integrieren unstimmig bin dann sollte mir vertraut werden und nicht darüber diskutiert ob mir das Paket weggenommen wird.
Maintainance-Gruppen fände ich eine sehr gute Idee. Auch eine Regelung nach der ein Paket raus fliegt, wenn es X Jahre ohne neues Release mitgeschleppt wird wäre sehr effektiv. Natürlich gibts Pakete die "Ausentwickelt" sind und wo es eben über 10 Jahre kaum mal ein neues Release gibt aber hier kann man ja immer ausnahmeanträge stellen. Ich kenne in dem Fall die Hintergründe nicht aber seit 2008 ungepflegt ist ein sehr langer Zeitraum
Von Oiler der Borg am Mi, 7. Dezember 2016 um 12:52 #
dass die nur alle Jubeljahre eine frische Version bringen können. Bei Debian ist man ja traditonell 97,2% der Zeit mint hingebungsvoll ausgefochtenen Kindergartenquereelen beschäftigt!
Genau. Und ein Parlament ist eine unnötige Quasselbude! /ironie
Ich finde, man hört erstaunlich wenig Querelen bei Debian. Zweitens finde ich es gut, dass man mal was hört, das zeigt, dass die Leute dort sich eben gemeinschaftlich mit den anstehenden Problemen beschäftigen.
Als wenn die keine anderen Sorgen haben.. Debian schafft nicht mal einen sauberen shutdown mit LVM und systemd hin.. Das Netz ist voll mit dem Mist... Eine echte Lösung Fehlanzeige! Puh und dann dieses gerede hier zum Thema Maintainer, naja
Das dachte ich auch erst. Im habe sonst grundsätzlich auch sehr gute Erfahrung mit systemd gemacht. Alles deutet darauf hin das nicht alle Partitionen ausgebunden werden können. Es gibt Hinweise das es eine Regression ist. LVM, MD, Verschlüsselung scheinen hier die tatsächlichen Probleme. Abhilfe schafft das nutzen klassischer Partitionen, was dann auch andere Nachteile mit sich bringt. Hm...
Das dachte ich auch erst. Im habe sonst grundsätzlich auch sehr gute Erfahrung mit systemd gemacht. Alles deutet darauf hin das nicht alle Partitionen ausgebunden werden können. Es gibt Hinweise das es eine Regression ist. LVM, MD, Verschlüsselung scheinen hier die tatsächlichen Probleme. Abhilfe schafft das nutzen klassischer Partitionen, was dann auch andere Nachteile mit sich bringt. Hm...
Zum Teil passt es. Das Problem taucht aber auch auf, wenn keine Verschlüsselung genutzt wird. Abhilfe schafft ganz sicher der Verzicht auf LVM. Zumindest haben die unzähligen Tests die ich gemacht habe, nichts gegenteiliges zu Tage gebracht. Auf bin jedenfalls für jeden Lösungsvorschlag dankbar, denn zu verharmlosen ist dieses Verhalten nicht.
Streit um verwaiste Pakete ist ja die eine Sache, die andere ist, wie viele CVEs mit niedriger Nummer bzw. sogar aus 2015 im Security-Tracker offen sind.
Bei anderen Distributionen ist das ähnlich, was aber nur selten etwas damit zu tun hat, dass man zu faul war oder ist, einen Bug zu fixen.
Ein solches Beispiel ist z.B. Imagemagick aus SLES 11, nachlesbar z.B. über die Lwn-Seite.
https://lwn.net/Articles/707992/
Zu dem Bug aus 2014 steht hier Interessantes: https://www.suse.com/de-de/security/cve/CVE-2014-9907.html
Der 2014er-Bug steht jetzt noch auf "Reserved", es liegt bis heute keine (auch nur ansatzweise detaillierte) Bescheibung vor.
Hier das Debian-Pendant zum Suse-Update: https://www.debian.org/security/2016/dsa-3652
Jetzt ist hoffentlich nachvollziehbar, warum Suse/SLES genauso wie Debian z.B. den 2014er-Imagemagick-Bug erst jetzt gefixt haben. Die Sicherheitsteams beider Distros haben keinen Fehler gemacht.
Gibt es für solche Fälle nicht NMUs?
NMUs sind soweit ich weiß nur für den Fall gedacht, dass der Maintainer nicht erreichbar ist oder bei kritischen Problemen zu lange nicht reagiert. Der Maintainer scheint hier aber durchaus aktiv zu sein, er möchte nur einfach nicht das Paket aktualisieren.
Warum kann man das Paket, welches ja open-source ist, nicht unter neuem Namen forken, auf den neuesten Stand bringen und dann in Debian nutzen? Dann koennte der alte Paketbetreuer machen was er will und die Community bekommt ein funktionierendes Paket.
Das kommt darauf an, wenn das Paket eine Library ist, dann müssten ja auch alle Programme gepatcht werden, die neue Library zu verwenden. Und Upstream wird man solche Patches niemals bekommen, wenn das ein Debian-internes Problem ist und in anderen Distros das Paket normal gepflegt wird.
Maintainern das Paket wegzunehmen, wenn sich diese nicht mehr darum kümmern, halte ich für die einzig sinnvolle Lösung. Außerdem sollte es generell mehr als einen Maintainer pro Paket geben, denn diese könnte ja kurzfristig nicht erreichbar sein (z.B. Krankheit).
Debian existiert seit 1993. Die Tatsache, dass dieses Problem bisher noch nie auftauchte spricht dafür, dass die getroffenen Regelungen funktionieren. Wahrscheinlich hat man bisher immer eine einvernehmliche Lösung gefunden. Die persönliche Paketbetreuung ist auch ein Garant für Verantwortung, Kontinuität und Qualität. Vielleicht ist es besser wenn das TC beim Paket GNU Global eine Ausnahmescheidung trifft.
Eine unsensible Diskussion um das Maintainment legt die Axt an das Selbstverständnis aller Mitwirkenden und hat die Potenz das ganze Debian Projekt zu gefährden.
Der Wunsch nach Teamarbeit sollte von den Maintainern selbst kommen.
Das Problem ist auch früher schon zig-Mal aufgetaucht, ein sehr bekanntes Beispiel ist Wine 1.0.1 in der Squeeze-Ära, das so als Wine 1.0.1 auch bereits in der vorgehenden Lenny-Zeit angeboten wurde. Das bedeutet, dass Debian Stable-Nutzer zwei Releases lang nur Wine 1.0.1 zur Verfügung hatten.
naja, selbst wenn es eine lib wäre kann der Fork bei der Installation ja einen symlink bereitstellen. Ging bei wodim ja auch (welches ja in der Folge selbst aus anderen Gründen praktisch un-maintained ist ...).
Man müsste halt zumindest Pakete, die nicht maintained sind, radikal aus der Distribution entfernen. Das würde natürlich in Einzelfällen sehr schmerzen, nur wäre Debian dadurch insgesamt sicherer.
Cdrkit samt wodim und genisomage ist so ein Fall. Wenn dann z.B. der Fileroller-Maintainer dann weiterhin auf einer Genisoimage-Abhängigkeit bestünde, dann müsste auch Fileroller entfernt werden, genauso wie Brasero und K3b.
Aktuell ignoriert so gut wie jede Distribution dieses Cdrkit-Problem: Cdrkit ist EOL, unmaintained, es findet keinerlei Weiterentwicklung statt. Dann lieber Xfburn und Libburnia.
Ich installiere ja ein aktuelles cdrecord einfach nach. Allerdings ist das CD Brennen an sich auch bald EOL Und BluRays sind für mich irgendwie nie ganz in den Distributionen angekommen ... wie geht den libburnia mit denen um, ist das akzeptabel?
Weil es Namenskonvetionen gibt und die vom Upstream Projekt abhängen. Das wiederum würde zur folge haben, dass Debian ein stable release (welches die Anforderungen an gleichbleibende Abhängigkeiten über die ganze Laufzeit, sowie keine neuen Pakete, hat) kaputt machen würde.
Also ja, natürlich wäre es möglich aber das wäre keine Lösung und würde nur zur Verwilderung des Paketjungles fühlen.
____
Das Paket jemanden weg nehmen sehe ich auch nicht als Lösung an. Bestünde die Chance, dass mein von mir gepflegtes Paket mir entrissen wird, weil ich z.B. im Krankenhaus liege oder länger Urlaub mache, würde ich kein Betreuer sein wollen. Ebenso ist es wenn ich mit der Entscheidung einen Patch zu integrieren unstimmig bin dann sollte mir vertraut werden und nicht darüber diskutiert ob mir das Paket weggenommen wird.
Maintainance-Gruppen fände ich eine sehr gute Idee. Auch eine Regelung nach der ein Paket raus fliegt, wenn es X Jahre ohne neues Release mitgeschleppt wird wäre sehr effektiv. Natürlich gibts Pakete die "Ausentwickelt" sind und wo es eben über 10 Jahre kaum mal ein neues Release gibt aber hier kann man ja immer ausnahmeanträge stellen. Ich kenne in dem Fall die Hintergründe nicht aber seit 2008 ungepflegt ist ein sehr langer Zeitraum
Vielen Dank fuer die konstruktiven Antworten! Habe bisher nicht so viel Einblick in diese Entwicklungsarbeit gehabt.
dass die nur alle Jubeljahre eine frische Version bringen können.
Bei Debian ist man ja traditonell 97,2% der Zeit mint hingebungsvoll ausgefochtenen Kindergartenquereelen beschäftigt!
Bei Debian wird regelmäßig "gerungen", dennoch setzen es viele ein. Und das sogar professionell. Und du bist nur ein Troll.
Genau. Und ein Parlament ist eine unnötige Quasselbude! /ironie
Ich finde, man hört erstaunlich wenig Querelen bei Debian. Zweitens finde ich es gut, dass man mal was hört, das zeigt, dass die Leute dort sich eben gemeinschaftlich mit den anstehenden Problemen beschäftigen.
Als wenn die keine anderen Sorgen haben.. Debian schafft nicht mal einen sauberen shutdown mit LVM und systemd hin.. Das Netz ist voll mit dem Mist... Eine echte Lösung Fehlanzeige! Puh und dann dieses gerede hier zum Thema Maintainer, naja
Das liegt jetzt aber an systemd, oder?
Oder was genau meinst Du?
Das dachte ich auch erst. Im habe sonst grundsätzlich auch sehr gute Erfahrung mit systemd gemacht. Alles deutet darauf hin das nicht alle Partitionen ausgebunden werden können. Es gibt Hinweise das es eine Regression ist. LVM, MD, Verschlüsselung scheinen hier die tatsächlichen Probleme. Abhilfe schafft das nutzen klassischer Partitionen, was dann auch andere Nachteile mit sich bringt. Hm...
Das dachte ich auch erst. Im habe sonst grundsätzlich auch sehr gute Erfahrung mit systemd gemacht. Alles deutet darauf hin das nicht alle Partitionen ausgebunden werden können. Es gibt Hinweise das es eine Regression ist. LVM, MD, Verschlüsselung scheinen hier die tatsächlichen Probleme. Abhilfe schafft das nutzen klassischer Partitionen, was dann auch andere Nachteile mit sich bringt. Hm...
Nachtrag: durch systemd fählt es halt erst sehr deutlich auf, dass etwas beim Herunterfahren nicht stimmt.
Der hier, oder? https://github.com/systemd/systemd/issues/1620
Zum Teil passt es. Das Problem taucht aber auch auf, wenn keine Verschlüsselung genutzt wird. Abhilfe schafft ganz sicher der Verzicht auf LVM. Zumindest haben die unzähligen Tests die ich gemacht habe, nichts gegenteiliges zu Tage gebracht. Auf bin jedenfalls für jeden Lösungsvorschlag dankbar, denn zu verharmlosen ist dieses Verhalten nicht.
vllt hilft dir dieser alte Thread im Debian Forum
Ja so bemerkt man das was nicht io ist. Leider hilft es nicht in meinem Fall da ich stark auf systemd setze. Q
Zumindest hättest du so den Vergleich, ob der Fehler auch mit SysVinit auftritt und erfolgreich ignoriert wird, oder ob er in systemd liegt.
Eigenartig dass die es schaffen, die umfangreichste und wichtigste Distribution in nur 2,8% der Zeit hinzubekommen. Da sage ich "Hut ab"!
Streit um verwaiste Pakete ist ja die eine Sache, die andere ist, wie viele CVEs mit niedriger Nummer bzw. sogar aus 2015 im Security-Tracker offen sind.
https://security-tracker.debian.org/tracker/status/release/stable
Die kann ich mangels Kenntnis nicht bewerten, aber allein die schiere Menge von offenbar älteren CVEs beeindruckt.
Das ist der Nachteil vom Vorteil von Debian stable, dass Pakete so lange betreut werden.
Ein paar Patches bleiben halt auf der Strecke.
Gibt es bei Red Hat / CentOs auch so eine Liste?
Bei Arch sind es dafür die neuen bugs.
Die Liste ist ungleich länger: https://bugs.archlinux.org/
Ich denke das betrifft CentOS
https://bugs.centos.org/view_all_bug_page.php
Hast du mal die Nummer deines Debian Bugreports, um das Problem besser zu verstehen?
Bei anderen Distributionen ist das ähnlich, was aber nur selten etwas damit zu tun hat, dass man zu faul war oder ist, einen Bug zu fixen.
Ein solches Beispiel ist z.B. Imagemagick aus SLES 11, nachlesbar z.B. über die Lwn-Seite.
https://lwn.net/Articles/707992/
Zu dem Bug aus 2014 steht hier Interessantes:
https://www.suse.com/de-de/security/cve/CVE-2014-9907.html
Der 2014er-Bug steht jetzt noch auf "Reserved", es liegt bis heute keine (auch nur ansatzweise detaillierte) Bescheibung vor.
Hier das Debian-Pendant zum Suse-Update:
https://www.debian.org/security/2016/dsa-3652
Jetzt ist hoffentlich nachvollziehbar, warum Suse/SLES genauso wie Debian z.B. den 2014er-Imagemagick-Bug erst jetzt gefixt haben. Die Sicherheitsteams beider Distros haben keinen Fehler gemacht.
Ergänzung zum Artikel: Für den Fall dass ein Betreuer schlicht inaktiv ist, gibt es bereits MIA (Missing In Action): https://wiki.debian.org/Teams/MIA
In diesem Fall ist er ja erreichbar, er weigert sich nur zu patchen.
Warum weigert er sich zu patchen?