Irgendwie habe ich das Gefühl, das es einfach ein Repository mehr gibt. Die meisten sind unter http://www.apt-get.org/ zusammengetragen.
Gerade lame und Co. gibt es schon in sehr sauberer Qualität von ftp://ftp.nerim.net/debian-marillat/. Warum soll ich da was verwenden, wo die Qualität unbekannt ist.
Nichts gegen die Idee, aber Sinnvoller wäre eine Zusammenarbeit mit den bestehenden Repositories.
1. Ich moechte am liebsten nur debian.org und eine einzige weitere Paketquelle, z.B. debian-unofficial.org, in meiner Source-list haben.
2. Ich habe den Anspruch, dass die Pakete nicht nur 'funktionieren', sondern auch schoen gemacht sind (was man bei Christian Marillat nicht sagen kann).
. man kann nicht mehrere Major-Versionen eines Paketes gleichzeitig installiert haben (wuerden sich ueberschreiben) . wenn er ueberhaupt bei mehrsprachig vorhandenen Paketen die anderen Sprachen paketiert hat, conflicten sie jeweils . debian/rules voellig chaotisch . debian/control ist bei seinen libraries falsch (benutzt kein provides, kein replace wo noetig), libraries haben auch den falschen namen (kein soname im namen) . benutzt keine alternatives fuer plugins . zum teil splittet er die pakete nicht oder zuwenig, wo es sinnvoll waere
>man kann nicht mehrere Major-Versionen eines Paketes gleichzeitig installiert haben (wuerden sich ueberschreiben) Warum sollte man das bei Programmen wollen? Bei Libs kann man das, wenn sich die Binärschnittstelle geändert hat, anderenfalls sehe ich da ebenfalls keinen Sinn drin.
> wenn er ueberhaupt bei mehrsprachig vorhandenen Paketen die anderen Sprachen paketiert hat, conflicten sie jeweils Welche Pakete sind überhaupt mehrsprachig vorhanden?
> libraries haben auch den falschen namen (kein soname im namen) Beispiele? libxvidcore4 ist doch richtig (/usr/lib/libxvidcore.so.4).
> zum teil splittet er die pakete nicht oder zuwenig, wo es sinnvoll waere Spiels du hier auf transcode an? Ich bin ehrlich gesagt froh, nicht jedes einzelne Im- und Export-Plugin für sich installieren zu müssen. Naja, da könnte man natürlich ein Meta-Paket transcode-all anfertigen.
"Warum sollte man das bei Programmen wollen? Bei Libs kann man das, wenn sich die Binärschnittstelle geändert hat, anderenfalls sehe ich da ebenfalls keinen Sinn drin."
Bei non-free Programmen ist fuer einen Teil der User manchmal die aeltere Version die bessere. Bei Libraries geht das mit seinen Pakete nicht, weil er sie nicht ensprechend paketiert.
"Beispiele? libxvidcore4 ist doch richtig (/usr/lib/libxvidcore.so.4)."
Seit er auf pool/ umgestellt hat, ist xvid (fast) richtig (das paket muesste eigentlich libxvidcore4.1 heissen). Bei lame ist die z.B.-dev aber immer noch falsch.
"Spiels du hier auf transcode an?" Nein, z.B. xvid. Solche Libraries sollten immer minimal paketiert sein.
Ah, und er macht natuerlich keinen Section-Unterschied. Bei ihm ist alles in Main
> Seit er auf pool/ umgestellt hat, ist xvid (fast) richtig (das paket muesste eigentlich libxvidcore4.1 heissen). Bei lame ist die z.B.-dev aber immer noch falsch. Warum müsste es libxvidcore4.1 heißen? Entscheidend ist doch nur die Major-Nummer und die hat sich nicht geändert. Sonst müsste man die Qt-Bibliothek in ein Paket wie libqt3.3.4 verpacken.
Ja, liblame-dev könnte man liblame0-dev nennen. Allerdings kann man die Header sowieso nicht parallel installieren, da sie sich überschneiden würden.
> Nein, z.B. xvid. Solche Libraries sollten immer minimal paketiert sein. Und was ist da falsch? In libxvidcore4 stecken doch nur die Lib selbst und README/Changelog. Bei euren Paketen ist das nicht anders.
> Ah, und er macht natuerlich keinen Section-Unterschied. Bei ihm ist alles in Main Das finde ich auch nicht so prickelnd. Allerdings ist strenggenommen (nach DFSG) sowieso alles non-free. Wäre es free, wäre das Paket auf ftp.debian.org zu finden.
Damit man XviD 1.0.3 (stable) und XviD 1.1.0-beta2 parallel installiert haben kann. Der QT Vergleich hinkt, weil Version a.b.c.d zu a.x.y.z binaer kompatibel ist.
"Und was ist da falsch?"
Stimmt, er paketiert die examples gar nicht.
"Allerdings ist strenggenommen (nach DFSG) sowieso alles non-free."
Quatsch. Nur weil etwas DFSG-frei ist (alles was bei mir in main ist), ist es noch lange nicht in Debian. Vielleicht willst du mal die unzaehligen 'Getting MPlayer into Debian'-Threads lesen?
> Damit man XviD 1.0.3 (stable) und XviD 1.1.0-beta2 parallel installiert haben kann. Der QT Vergleich hinkt, weil Version a.b.c.d zu a.x.y.z binaer kompatibel ist. Sind XviD 1.0.3 und 1.1.0-beta2 auch. Anderenfalls würde ich mal die Entwickler von XviD anhauen, warum sie die Majorversion der Lib nicht auf 5 erhöhen! Ich hatte jedenfalls keine Probleme beim Update von XviD 1.0.3 auf 1.1.0-beta1. Alle Anwendungen, die auf XviD aufgesetzt hatten, liefen weiterhin fehlerfrei (so fehlerfrei wie vor dem Update).
> Quatsch. Nur weil etwas DFSG-frei ist (alles was bei mir in main ist), ist es noch lange nicht in Debian. Vielleicht willst du mal die unzaehligen 'Getting MPlayer into Debian'-Threads lesen? Die brauche ich nicht zu lesen. MPlayer ist aus rechtlichen Gründen nicht dabei, genauso wie die libdvdcss2, die daher für mich auch nicht DFSG-frei ist, weil ich eben sie eben nicht für jeden Zweck einsetzen darf. Ich darf sie überhaupt nicht einsetzen.
Bei XviD ist der Grund fuer die zwei Versionen darin, dass das eine stable ist, das andere beta.
MPlayer ist aus patentrechlichen Ueberlegungen nicht in Debian, nicht aus urheberrechtlichen. DFSG handeln aber von Urheberrecht. libdvdcss2 *ist* DFSG-frei.
> Bei XviD ist der Grund fuer die zwei Versionen darin, dass das eine stable ist, das andere beta. Damit ist die Bezeichnung libxvidcore4.1 eher eine subjektive Entscheidung und nicht aus den Debian-Policies abzuleiten. Es hat also weniger damit zu tun, dass die Pakete von Marillat schlecht gebaut wären, sondern damit, dass du sie gerne anders bezeichnet hättest, um verschiedene Versionen parallel installieren zu können. Das ist dein gutes Recht. Rarewares geht übrigens soweit, alle möglichen Patchvarianten der libvorbis als DEB-Paket auszuliefern, sodass man die freie Wahl hat, welcher Variante man den Vorzug gibt.
> MPlayer ist aus patentrechlichen Ueberlegungen nicht in Debian, nicht aus urheberrechtlichen. Sagte ich doch, aus rechtlichen Gründen.
> DFSG handeln aber von Urheberrecht. Ist mir schon klar. Sonst dürfte freetype2 nicht mit Bytecode-Interpreter-Support kompiliert ausgeliefert werden. Hier sieht man mal, dass sich die Debian-Entwickler selbst nicht einig sind, was free und was non-free ist.
> libdvdcss2 *ist* DFSG-frei. Von der Lizenz her ja. Hab ich was anderes behauptet? Ich sagte ja ausdrücklich "für mich". Mir hat der Staat bei dieser Bibliothek die Freiheiten genommen. Ich darf sie weder verbreiten noch nutzen.
> Bei non-free Programmen ist fuer einen Teil der User manchmal die aeltere Version die bessere. Bei Libraries geht das mit seinen Pakete nicht, weil er sie nicht ensprechend paketiert. Wie kann man denn bei euch Lame 3.96.1 und Lame 3.95.1 parallel installieren? Vielleicht hält ja jemand Lame 3.95.1 für qualitativ besser. Da muss man sich halt Lame 3.95.1 irgendwoher besorgen und auf Hold setzen und genau das geht auch mit den Paketen von Marillat.
Bei Lame gibt es keinen Grund, eine aeltere Version zu benutzen, da die letzte die beste ist.
Darum habe ich ja auch geschrieben, dass bei *non-free* die aelteren Versionen oft trotzdem noch viel benutzt werden, weil die neue nicht unbedingt besser ist. Bei freien Programmen ist meistens die neuere Version besser.
> Bei freien Programmen ist meistens die neuere Version besser. Tja, meistens, nicht immer. Ich erinnere nur an Lame 3.90.1, welches auf Grund der Patches von Dibrom besser war als die nachfolgenden Versionen ohne diese.
>>man kann nicht mehrere Major-Versionen eines Paketes gleichzeitig installiert haben > Warum sollte man das bei Programmen wollen? Bei Libs kann man das, wenn sich die > Binärschnittstelle geändert hat, anderenfalls sehe ich da ebenfalls keinen Sinn drin.
Z.b. weil Erweiterungen an bestimmte Programm-Versionen gekoppelt sind. Oder weil man die alte Stabilere und bewaehrte Version weiter nutzen will solange man die Neue austestet. Oder weil die verschiedenen Versionen verschiedene Bugs bei verschiedenen Szenarien haben.
Dann müsste man das konsequenterweise aber bei allen Anwendungen machen. Zum Beispiel hat sich meiner Meinung nach KHTML auf KDE 3.4 verglichen mit der Version aus KDE 3.3 verschlechtert. Ich kann aber nicht einfach KHTML 3.3 neben 3.4 installieren. Da muss ich schon KDE mit konstruct selbst kompilieren.
Der korrekte Weg bei freier Software ist, dass man dann die Fehler der neuen Version behebt und sie wieder so gut macht wie die vorherige.
Bei nicht freier Software, aus welchen Gruenden man sie jetzt einsetzten muss/will steht nicht zur Diskussion, kann man das nicht. Deshalb habe ich fuer manche Pakete, wo es Sinn macht eben beide/mehrere Versionen drin.
> Deshalb habe ich fuer manche Pakete, wo es Sinn macht eben beide/mehrere Versionen drin. Das ist doch in Ordnung.
Nur: Was machst du beim Flash-Plugin? Du kannst zwar via update-alternatives später eventuell zwischen den Plugins für Flash 7 und 8 wechseln, aber da kann man doch genauso gut einfach das andere Plugin installieren, welches via Conflicts das andere deinstalliert, so wie es bei VDR 1.2 vs. VDR 1.3 auch ist. Für eine Parallelinstallation sehe ich hier also keinen Sinn.
Ja, nur würde ich nicht beide installieren, da man ja nur eines der beiden nutzen kann und root durch den Symlink in /usr/lib/*/plugins das jeweilige Flash-Plugin vorgibt.
Angenommen, es gaebe Flash Player 8. Dann wird es Leute geben, die die alte Version zu Test-Zwecken noch benoetigen. Diese koennen beide installieren und per alternatives bequem wechseln, ohne Zugang zu den Paketen zu haben und ohne immer ein hin- und herinstallieren der Pakete zu machen. Nicht mehr, nicht weniger.
Fuer die, die Symlinks moegen und keine Rootrechte an ihrem System haben, duerfen auch gerne einen ensprechenden Link in ~/.mozilla machen.
Neben eines nicht chaotischen debian/ ist das der einzige Unterschied zwischen meinem Flash Player Paket und dem von Marillat. Ich haette auch sein Paket unveraendert nehmen koennen, habe mir dann aber erlaubt, diese Aenderung zu machen weil sie in manchen Faellen fuer ein paar wenige Leute einen Vorteil bringt, alle anderen aber nicht behindert. flashplayer7 wird auch bei 'apt-get install flashplayer' installiert, ensprechende Provides: sind natuerlich gesetzt.
Wenn du diese Aenderungen fuer nicht sinnvoll erachtest, dann mach das. Wenn du lieber Marillats Pakete verwendest, dann mach das. Seine Pakete sind nicht schlecht als dass sie nicht funktionieren wuerden - ich finde sie nicht aestetisch genug und habe den Anspruch, schoenere Pakete zu machen.
Bisher gabs das nicht. Ich bin der Meinung, dass man erstmal etwas beginnen muss, dann kann man darueber reden und Dinge aendern/anpassen. Manchmal drohen Dinge, bevor ueberhaupt etwas gemacht wurde, 'zerredet' zu werden. Das wollte ich nicht.
Mal sehen was die Zukunft bringt, die erste Charge Pakete ist fertig, naechste Woche kommt die zweite. Ich bin jedenfalls offen fuer fast alles und an mir soll es nicht liegen.
Mittlerweile habe ich mir angewöhnt Pakete die ich in der aktuellen Fassung brauche oder nichtvorhandene Pakete aus den Quellen selber zu kompilieren und per checkinstall zu installieren. So habe ich die von mir installierten Pakete in der Debian Paketdatenbank und kann jederzeit diese deinstallieren.
Das einzige wo dieses verfahren nervt ist, wenn eine lange Abhängigkeitsliste vorhanden ist.
geht das einem nicht auf die nerven, wenn man staendig sein Sytem kompilieren muss? Ich benutze gentoo sei 2003, aber es ist nur eine Frage der Zeit bis ich es mit ubuntu ersetze. Mein Fazit: Gentoo ist nur für diejenigen die u.a. als Hauptaufgabe die Aktualität ihres Systems haben. Wenn ich arbeite geht schonmal ein halbes Jahr vorrüber ohne das ich an ein update denke. Dann heisst es tagelang durchkompilieren bis man ein aktuelles System hat.
@ popel: toll! Sachliche und bereichernde on topic Bemerkungen wie diese sollte es in jeder Diskussion geben, damit man weiß wie gut die bisherige Diskussion eigentlich gewesen ist. Ich bin heilfroh kein System benutzen zu müssen, daß einem laufend Kompilierorgien "aufbrummt". Und wenn Du für ein paar popelige Pakete immer gleich ein emerge world machst (und gar keinen Vorteil von den Use flags und dem anderen klimbim machst) ... im Übrigen spart ein durchoprimiertes Gentoo System die durch die Kompilationen verlorene Zeit durch den schnelleren Betrieb eh nie wieder ein. Daher ist es auch einfach nur ein nettes Hobby. Klar mann man im Hintergrund kompilieren, aber schneller wird das System davon sicher auch nicht ...
Opera ist vorhanden und Netbeans, aber das war dann auch schon alles interessante. Mal sehen wie sich das entwickelt, aber ohne Mplayer wird es eher schnöde.
Stimmt! Ich finde die Idee sehr nützlich: Sie vereinfacht die Antwort auf regelmäßig gestellte Fragen, vermeidet sie (mit steigendem Bekannheitsgrad) vielleicht sogar, und ist einfach nur praktisch, wenn sich mehrere Maintainer ein Repository teilen.
ich bin da ein bischen aus dem Thema, aber wie sieht es mit dem Rechtlichen aus? Dort wird libdvdcss und einige verschiedene Binaries angeboten (z.B. Skype). Es hat ja Gründe gegeben warum diese Sachen nicht in Debian sind. Steht man nicht in Deutschland auf dem Glatteis, wenn man diese Programme anbietet und zum Download bereitstellt?
libdvdcss koennte in Deutschland u.U. ein Problem sein. In der Schweiz ist es legal (wie in vielen anderen Laendern auch). Ich weis (noch) nicht, wie euer Urheberrecht in der juristischen Praxis bei euch gehandhabt wird.
Skype ist unproblematisch. Die Lizenz stinkt zwar, aber es ist voellig legal. Ich versuche natuerlich immer noch, Skype ins offizielle Archiv zu kriegen, vergl. #298763. In der 'Zwischenzeit' sind die Pakete ueber debian-unofficial.org erhaeltlich.
(Allerdings schaut es im Moment nicht danach aus, als ob sie jemals in Debian reinkommen werden. Skype hat auf mehrere Anfragen waehrend Monaten nicht reagiert - vermutlich besteht einfach kein Interesse daran).
>Ich weis (noch) nicht, wie euer Urheberrecht in der juristischen Praxis bei euch gehandhabt wird.
Oh, ich habe nicht mitbekommen, dass Du in der Schweiz sitzt. Da habe ich gar keinen Einblick in die Rechtslage. Ich nehme aber mal an, dass dort die Sache etwas einfacher ist. Nicht umsonst gibt es Firmen die ihren Sitz wegen dieser Dinge in die Schweiz verlegt haben.
Danke für Deine Ausführungen. Man sieht, dass sich jemand mit dem Thema beschäftigt hat und nicht naiv in so ein Projekt gestolpert ist.
Was ich noch vergessen hab zu sagen.. ich werde zu jedem Paket ein ensprechende Notiz machen, warum die lizenz nicht DFSG-frei ist, was man trotzdem darf, warum es nicht in Debian ist und, falls vorhanden, wie der Status der Integration ist.
Das dauert aber noch ein bisschen, ich moechte vorher noch ein paar zusaetzliche Pakete nachreichen.
Das wird auf jeden Fall ein ziemlicher Renner werden, denn genau das hat Debian meiner Meinung nach noch gefehlt. SuSE hat sein packman, Mandriva hat seine penguin liberation front und Debian bekommt ein unofficial.org. Bisher bin ich aber mit den Paketen von Marillat recht zufrieden. Sind den zum Beispiel auch aktuelle KDE Pakete geplant für die Zukunft? Klar, das ist ein dicker dicker Brocken ...
Ich mache nur Pakete, die ueberhaupt nicht in Debian enthalten sind. Aktuellere KDE Pakete gibt es vom KDE Packageing Team auf pkg-kde.alioth.debian.org
Gerade lame und Co. gibt es schon in sehr sauberer Qualität von ftp://ftp.nerim.net/debian-marillat/. Warum soll ich da was verwenden, wo die Qualität unbekannt ist.
Nichts gegen die Idee, aber Sinnvoller wäre eine Zusammenarbeit mit den bestehenden Repositories.
Ich verwende eigentlich nur 2 inoffizielle Debian-Repositories: das von Christian Marillat und das von Tobias Grimm.
1. Ich moechte am liebsten nur debian.org und eine einzige weitere Paketquelle, z.B. debian-unofficial.org, in meiner Source-list haben.
2. Ich habe den Anspruch, dass die Pakete nicht nur 'funktionieren', sondern auch schoen gemacht sind (was man bei Christian Marillat nicht sagen kann).
Da Zusammenführen mehrerer Quellen zu einem Repository ist danach ja immernoch eine Option.
. wenn er ueberhaupt bei mehrsprachig vorhandenen Paketen die anderen Sprachen paketiert hat, conflicten sie jeweils
. debian/rules voellig chaotisch
. debian/control ist bei seinen libraries falsch (benutzt kein provides, kein replace wo noetig), libraries haben auch den falschen namen (kein soname im namen)
. benutzt keine alternatives fuer plugins
. zum teil splittet er die pakete nicht oder zuwenig, wo es sinnvoll waere
Warum sollte man das bei Programmen wollen? Bei Libs kann man das, wenn sich die Binärschnittstelle geändert hat, anderenfalls sehe ich da ebenfalls keinen Sinn drin.
> wenn er ueberhaupt bei mehrsprachig vorhandenen Paketen die anderen Sprachen paketiert hat, conflicten sie jeweils
Welche Pakete sind überhaupt mehrsprachig vorhanden?
> libraries haben auch den falschen namen (kein soname im namen)
Beispiele? libxvidcore4 ist doch richtig (/usr/lib/libxvidcore.so.4).
> zum teil splittet er die pakete nicht oder zuwenig, wo es sinnvoll waere
Spiels du hier auf transcode an? Ich bin ehrlich gesagt froh, nicht jedes einzelne Im- und Export-Plugin für sich installieren zu müssen. Naja, da könnte man natürlich ein Meta-Paket transcode-all anfertigen.
Bei non-free Programmen ist fuer einen Teil der User manchmal die aeltere Version die bessere. Bei Libraries geht das mit seinen Pakete nicht, weil er sie nicht ensprechend paketiert.
"Beispiele? libxvidcore4 ist doch richtig (/usr/lib/libxvidcore.so.4)."
Seit er auf pool/ umgestellt hat, ist xvid (fast) richtig (das paket muesste eigentlich libxvidcore4.1 heissen). Bei lame ist die z.B.-dev aber immer noch falsch.
"Spiels du hier auf transcode an?"
Nein, z.B. xvid. Solche Libraries sollten immer minimal paketiert sein.
Ah, und er macht natuerlich keinen Section-Unterschied. Bei ihm ist alles in Main
Warum müsste es libxvidcore4.1 heißen?
Entscheidend ist doch nur die Major-Nummer und die hat sich nicht geändert. Sonst müsste man die Qt-Bibliothek in ein Paket wie libqt3.3.4 verpacken.
Ja, liblame-dev könnte man liblame0-dev nennen. Allerdings kann man die Header sowieso nicht parallel installieren, da sie sich überschneiden würden.
> Nein, z.B. xvid. Solche Libraries sollten immer minimal paketiert sein.
Und was ist da falsch? In libxvidcore4 stecken doch nur die Lib selbst und README/Changelog. Bei euren Paketen ist das nicht anders.
> Ah, und er macht natuerlich keinen Section-Unterschied. Bei ihm ist alles in Main
Das finde ich auch nicht so prickelnd. Allerdings ist strenggenommen (nach DFSG) sowieso alles non-free. Wäre es free, wäre das Paket auf ftp.debian.org zu finden.
Damit man XviD 1.0.3 (stable) und XviD 1.1.0-beta2 parallel installiert haben kann. Der QT Vergleich hinkt, weil Version a.b.c.d zu a.x.y.z binaer kompatibel ist.
"Und was ist da falsch?"
Stimmt, er paketiert die examples gar nicht.
"Allerdings ist strenggenommen (nach DFSG) sowieso alles non-free."
Quatsch. Nur weil etwas DFSG-frei ist (alles was bei mir in main ist), ist es noch lange nicht in Debian. Vielleicht willst du mal die unzaehligen 'Getting MPlayer into Debian'-Threads lesen?
Sind XviD 1.0.3 und 1.1.0-beta2 auch. Anderenfalls würde ich mal die Entwickler von XviD anhauen, warum sie die Majorversion der Lib nicht auf 5 erhöhen!
Ich hatte jedenfalls keine Probleme beim Update von XviD 1.0.3 auf 1.1.0-beta1. Alle Anwendungen, die auf XviD aufgesetzt hatten, liefen weiterhin fehlerfrei (so fehlerfrei wie vor dem Update).
> Quatsch. Nur weil etwas DFSG-frei ist (alles was bei mir in main ist), ist es noch lange nicht in Debian. Vielleicht willst du mal die unzaehligen 'Getting MPlayer into Debian'-Threads lesen?
Die brauche ich nicht zu lesen. MPlayer ist aus rechtlichen Gründen nicht dabei, genauso wie die libdvdcss2, die daher für mich auch nicht DFSG-frei ist, weil ich eben sie eben nicht für jeden Zweck einsetzen darf. Ich darf sie überhaupt nicht einsetzen.
MPlayer ist aus patentrechlichen Ueberlegungen nicht in Debian, nicht aus urheberrechtlichen. DFSG handeln aber von Urheberrecht. libdvdcss2 *ist* DFSG-frei.
Damit ist die Bezeichnung libxvidcore4.1 eher eine subjektive Entscheidung und nicht aus den Debian-Policies abzuleiten.
Es hat also weniger damit zu tun, dass die Pakete von Marillat schlecht gebaut wären, sondern damit, dass du sie gerne anders bezeichnet hättest, um verschiedene Versionen parallel installieren zu können. Das ist dein gutes Recht. Rarewares geht übrigens soweit, alle möglichen Patchvarianten der libvorbis als DEB-Paket auszuliefern, sodass man die freie Wahl hat, welcher Variante man den Vorzug gibt.
> MPlayer ist aus patentrechlichen Ueberlegungen nicht in Debian, nicht aus urheberrechtlichen.
Sagte ich doch, aus rechtlichen Gründen.
> DFSG handeln aber von Urheberrecht.
Ist mir schon klar. Sonst dürfte freetype2 nicht mit Bytecode-Interpreter-Support kompiliert ausgeliefert werden. Hier sieht man mal, dass sich die Debian-Entwickler selbst nicht einig sind, was free und was non-free ist.
> libdvdcss2 *ist* DFSG-frei.
Von der Lizenz her ja. Hab ich was anderes behauptet? Ich sagte ja ausdrücklich "für mich". Mir hat der Staat bei dieser Bibliothek die Freiheiten genommen. Ich darf sie weder verbreiten noch nutzen.
> Bei non-free Programmen ist fuer einen Teil der User manchmal die aeltere Version die bessere. Bei Libraries geht das mit seinen Pakete nicht, weil er sie nicht ensprechend paketiert.
Wie kann man denn bei euch Lame 3.96.1 und Lame 3.95.1 parallel installieren? Vielleicht hält ja jemand Lame 3.95.1 für qualitativ besser.
Da muss man sich halt Lame 3.95.1 irgendwoher besorgen und auf Hold setzen und genau das geht auch mit den Paketen von Marillat.
Darum habe ich ja auch geschrieben, dass bei *non-free* die aelteren Versionen oft trotzdem noch viel benutzt werden, weil die neue nicht unbedingt besser ist. Bei freien Programmen ist meistens die neuere Version besser.
Tja, meistens, nicht immer.
Ich erinnere nur an Lame 3.90.1, welches auf Grund der Patches von Dibrom besser war als die nachfolgenden Versionen ohne diese.
> Warum sollte man das bei Programmen wollen? Bei Libs kann man das, wenn sich die
> Binärschnittstelle geändert hat, anderenfalls sehe ich da ebenfalls keinen Sinn drin.
Z.b. weil Erweiterungen an bestimmte Programm-Versionen gekoppelt sind. Oder weil man die alte Stabilere und bewaehrte Version weiter nutzen will solange man die Neue austestet. Oder weil die verschiedenen Versionen verschiedene Bugs bei verschiedenen Szenarien haben.
Zum Beispiel hat sich meiner Meinung nach KHTML auf KDE 3.4 verglichen mit der Version aus KDE 3.3 verschlechtert.
Ich kann aber nicht einfach KHTML 3.3 neben 3.4 installieren. Da muss ich schon KDE mit konstruct selbst kompilieren.
Bei nicht freier Software, aus welchen Gruenden man sie jetzt einsetzten muss/will steht nicht zur Diskussion, kann man das nicht. Deshalb habe ich fuer manche Pakete, wo es Sinn macht eben beide/mehrere Versionen drin.
Das ist doch in Ordnung.
Nur: Was machst du beim Flash-Plugin? Du kannst zwar via update-alternatives später eventuell zwischen den Plugins für Flash 7 und 8 wechseln, aber da kann man doch genauso gut einfach das andere Plugin installieren, welches via Conflicts das andere deinstalliert, so wie es bei VDR 1.2 vs. VDR 1.3 auch ist. Für eine Parallelinstallation sehe ich hier also keinen Sinn.
klar, setzt aber Internet oder sonstiger Zugang zu den Paketen voraus.
Wir drehen uns im Kreis.
Fuer die, die Symlinks moegen und keine Rootrechte an ihrem System haben, duerfen auch gerne einen ensprechenden Link in ~/.mozilla machen.
Neben eines nicht chaotischen debian/ ist das der einzige Unterschied zwischen meinem Flash Player Paket und dem von Marillat. Ich haette auch sein Paket unveraendert nehmen koennen, habe mir dann aber erlaubt, diese Aenderung zu machen weil sie in manchen Faellen fuer ein paar wenige Leute einen Vorteil bringt, alle anderen aber nicht behindert. flashplayer7 wird auch bei 'apt-get install flashplayer' installiert, ensprechende Provides: sind natuerlich gesetzt.
Wenn du diese Aenderungen fuer nicht sinnvoll erachtest, dann mach das. Wenn du lieber Marillats Pakete verwendest, dann mach das. Seine Pakete sind nicht schlecht als dass sie nicht funktionieren wuerden - ich finde sie nicht aestetisch genug und habe den Anspruch, schoenere Pakete zu machen.
Was sagen Maintainer, z.B. C.M., wenn sie gebeten werden, die von Dir favorisierten Änderungen in ihre Pakete einfließen zu lassen?
Oder gab es solche "Besprechungen" gar nicht?
Mal sehen was die Zukunft bringt, die erste Charge Pakete ist fertig, naechste Woche kommt die zweite. Ich bin jedenfalls offen fuer fast alles und an mir soll es nicht liegen.
Kommt mir seltsam vor.
So habe ich die von mir installierten Pakete in der Debian Paketdatenbank und kann jederzeit diese deinstallieren.
Das einzige wo dieses verfahren nervt ist, wenn eine lange Abhängigkeitsliste vorhanden ist.
;=)
Ich benutze gentoo sei 2003, aber es ist nur eine Frage der Zeit bis ich es mit ubuntu ersetze.
Mein Fazit: Gentoo ist nur für diejenigen die u.a. als Hauptaufgabe die Aktualität ihres Systems haben.
Wenn ich arbeite geht schonmal ein halbes Jahr vorrüber ohne das ich an ein update denke.
Dann heisst es tagelang durchkompilieren bis man ein aktuelles System hat.
Wenn ich Programme Kompilieren will kann ich auch Gentoo benutzen :>
Danke für die Mühe!
Vielen Dank!
Hallo,
ich bin da ein bischen aus dem Thema, aber wie sieht es mit dem Rechtlichen aus? Dort wird libdvdcss und einige verschiedene Binaries angeboten (z.B. Skype). Es hat ja Gründe gegeben warum diese Sachen nicht in Debian sind. Steht man nicht in Deutschland auf dem Glatteis, wenn man diese Programme anbietet und zum Download bereitstellt?
Lars
Skype ist unproblematisch. Die Lizenz stinkt zwar, aber es ist voellig legal. Ich versuche natuerlich immer noch, Skype ins offizielle Archiv zu kriegen, vergl. #298763. In der 'Zwischenzeit' sind die Pakete ueber debian-unofficial.org erhaeltlich.
(Allerdings schaut es im Moment nicht danach aus, als ob sie jemals in Debian reinkommen werden. Skype hat auf mehrere Anfragen waehrend Monaten nicht reagiert - vermutlich besteht einfach kein Interesse daran).
Oh, ich habe nicht mitbekommen, dass Du in der Schweiz sitzt. Da habe ich gar keinen Einblick in die Rechtslage. Ich nehme aber mal an, dass dort die Sache etwas einfacher ist. Nicht umsonst gibt es Firmen die ihren Sitz wegen dieser Dinge in die Schweiz verlegt haben.
Danke für Deine Ausführungen. Man sieht, dass sich jemand mit dem Thema beschäftigt hat und nicht naiv in so ein Projekt gestolpert ist.
Lars
Das dauert aber noch ein bisschen, ich moechte vorher noch ein paar zusaetzliche Pakete nachreichen.
Die aktuelle Paketauswahl sieht schon sehr vielversprechend aus!
Gruß
Tuxracer
.
MfG