Wenn man KDE z.B. über kde-core in Debian installiert, dann wäre es IMHO doch besser, dass keine libmad mitinstalliert wird, wenn man überhaupt keine MP3-Abspielsoftware installiert.
Eine MP3-Abspielbibliothek, die gemäß diesem Szenario niemals benutzt und deshalb auch nicht gebraucht wird, aber trotzdem als feste Abhängigkeit zwangsweise bei der Installation von KDE unter Debian mit installiert wird, hat in diesem Fall IMHO auf dem System nichts verloren.
OpenMoko hatte vor Monaten mit einem seiner Handys einen anscheinend ähnlich gelagerten Fall. Man hat leider nie mehr etwas davon gehört, vor allem nichts davon, wie die Patentsache mit Sisvel ausgegangen ist.
> Wenn man KDE z.B. über kde-core in Debian installiert, dann wäre es IMHO doch besser, dass > keine libmad mitinstalliert wird, wenn man überhaupt keine MP3-Abspielsoftware installiert.
Das wichtigste Detail vorweg: Die Abhängigkeit zu einer Library legt man während des kompilierens der Applikation fest und nicht zum Zeitpunkt der Installation.
Es wäre deshalb nicht besser, da damit Teile von KDE gegen eine Library gelinkt wären, die auf dem System nicht vorhanden ist. Sobald du eine Funktion in einer Applikation aufrufen würdest welche die Library benötigt, würde die Applikation auf die Nase fallen. Das ist kein akzeptabler Zustand für eine stabile Distribution, auch wenn es dir persönlich in spezifischen Einzelfällen vielleicht nichts ausmachen würde.
Einzige saubere Alternative wäre, die Applikation nicht gegen die ungewünschte Library zu linken, dann würden aber diejenigen mosern, die die Funktionalität nutzen möchten, dann die wäre dann nicht mehr vorhanden.
Debian müsste also zwei Pakete zur Verfügung stellen, eines welches gegen die Library gelinkt ist und ein anderes, welches nicht dagegen gelinkt ist. Und da es zig Libraries gibt und zig Applikationen in welchen sie vorkommen, würde sich das Debian-Paketarchiv schnell verzehnfachen, um alle gewünschten Kombinationen der Anwender abzudecken. Dieser Weg ist also nicht gangbar. Jedoch liefert Debian nicht umsonst auch die Quellen mit, welche auf einfache Weise für die eigenen Bedürfnisse angepasst, kompiliert, zu Debian-Paketen gebaut und installiert werden können.
Ich glaube, mittlerweile würde ein Paket reichen, ohne feste libmad-Abhängigkeit (siehe Kubuntu). KDE braucht die libmad nicht zwingend, um zu funktionieren. Bis zu einem gewissen Grade ist das halt auch Politik. Zudem ist die automatische Mit-Installation auch der empfohlenen Pakete in Debian Lenny (im Gegensatz zu Etch) "fest" voreingestellt, der Nutzer würde also nichts merken, wenn libmad in diesem Sinne optional, d.h. nur "empfohlen" wäre. Ich finde meinen obigen Vorschlag deshalb nicht allzu dämlich.
Es ist kein manueller Prozess wo der Paketbetreuer "würfelt" welche Library er wo einsortiert, sondern ein automatischer. Die Executable hängt von der Library ab weil sie dagegen gelinkt ist, folglich hängt auch das Paket davon ab.
Die Frage ist, soll der Paketbetreuer ein Programm mit der maximalen Funktionalität übersetzen um den maximal möglichen Nutzen und die universellsten Einsatzmöglichkeiten für die verschiedensten Belange der verschiedenen Nutzer herauszuholen, oder soll er Funktionalität wegstreichen und nach welchen Kriterien. Dazu gibt es natürlich verschiedene Antworten von verschiedenen Interessensgruppen.
Ich kann dein Patentargument zwar nachvollziehen, aber es ist nicht ganz schlüssig und konsequent. Denn würde man jede Software entfernen die ein Patent verletzt, welches in einem Land in dem die Distribution verbreitet wird gültig ist, dann würde kaum noch etwas übrig bleiben. Man denke dabei z.B. nur an die Softwarepatente aus den USA.
Wenn man KDE z.B. über kde-core in Debian installiert, dann wäre es IMHO doch besser, dass keine libmad mitinstalliert wird, wenn man überhaupt keine MP3-Abspielsoftware installiert.
Eine MP3-Abspielbibliothek, die gemäß diesem Szenario niemals benutzt und deshalb auch nicht gebraucht wird, aber trotzdem als feste Abhängigkeit zwangsweise bei der Installation von KDE unter Debian mit installiert wird, hat in diesem Fall IMHO auf dem System nichts verloren.
OpenMoko hatte vor Monaten mit einem seiner Handys einen anscheinend ähnlich gelagerten Fall. Man hat leider nie mehr etwas davon gehört, vor allem nichts davon, wie die Patentsache mit Sisvel ausgegangen ist.
> keine libmad mitinstalliert wird, wenn man überhaupt keine MP3-Abspielsoftware installiert.
Das wichtigste Detail vorweg: Die Abhängigkeit zu einer Library legt man während des kompilierens der Applikation fest und nicht zum Zeitpunkt der Installation.
Es wäre deshalb nicht besser, da damit Teile von KDE gegen eine Library gelinkt wären, die auf dem System nicht vorhanden ist. Sobald du eine Funktion in einer Applikation aufrufen würdest welche die Library benötigt, würde die Applikation auf die Nase fallen. Das ist kein akzeptabler Zustand für eine stabile Distribution, auch wenn es dir persönlich in spezifischen Einzelfällen vielleicht nichts ausmachen würde.
Einzige saubere Alternative wäre, die Applikation nicht gegen die ungewünschte Library zu linken, dann würden aber diejenigen mosern, die die Funktionalität nutzen möchten, dann die wäre dann nicht mehr vorhanden.
Debian müsste also zwei Pakete zur Verfügung stellen, eines welches gegen die Library gelinkt ist und ein anderes, welches nicht dagegen gelinkt ist. Und da es zig Libraries gibt und zig Applikationen in welchen sie vorkommen, würde sich das Debian-Paketarchiv schnell verzehnfachen, um alle gewünschten Kombinationen der Anwender abzudecken. Dieser Weg ist also nicht gangbar. Jedoch liefert Debian nicht umsonst auch die Quellen mit, welche auf einfache Weise für die eigenen Bedürfnisse angepasst, kompiliert, zu Debian-Paketen gebaut und installiert werden können.
Zudem ist die automatische Mit-Installation auch der empfohlenen Pakete in Debian Lenny (im Gegensatz zu Etch) "fest" voreingestellt, der Nutzer würde also nichts merken, wenn libmad in diesem Sinne optional, d.h. nur "empfohlen" wäre.
Ich finde meinen obigen Vorschlag deshalb nicht allzu dämlich.
Die Frage ist, soll der Paketbetreuer ein Programm mit der maximalen Funktionalität übersetzen um den maximal möglichen Nutzen und die universellsten Einsatzmöglichkeiten für die verschiedensten Belange der verschiedenen Nutzer herauszuholen, oder soll er Funktionalität wegstreichen und nach welchen Kriterien. Dazu gibt es natürlich verschiedene Antworten von verschiedenen Interessensgruppen.
Ich kann dein Patentargument zwar nachvollziehen, aber es ist nicht ganz schlüssig und konsequent. Denn würde man jede Software entfernen die ein Patent verletzt, welches in einem Land in dem die Distribution verbreitet wird gültig ist, dann würde kaum noch etwas übrig bleiben. Man denke dabei z.B. nur an die Softwarepatente aus den USA.