Hi,
ich bin bei Backups ueber /etc/alternatives unter Debian gestolpert und erachte das als ueberfluessig. Der Aesthetik wegen wuerde ich das gern entfernen. Gibt es da irgendwas schlimmes zu erwarten bzw. setzt irgendwas zwingend darauf auf?
bye, Rocco
* Rocco Rutte wrote:
ich bin bei Backups ueber /etc/alternatives unter Debian gestolpert und erachte das als ueberfluessig.
mutig
Der Aesthetik wegen wuerde ich das gern entfernen. Gibt es da irgendwas schlimmes zu erwarten bzw. setzt irgendwas zwingend darauf auf?
Deine Nerven. ;-) Mal im Ernst, über das alternatives-System wird z.B. die Wahl des Windowmanager geregelt oder auch welcher Java-Compiler benutzt wird und noch eine Menge mehr.
man update-alternatives hilft dir weiter
Ich halte das für sehr clever, und würde mir das nicht kaputt machen.
Jan
Hi,
* Jan Rakelmann [03-01-22 20:15:21 +0100] wrote:
- Rocco Rutte wrote:
ich bin bei Backups ueber /etc/alternatives unter Debian gestolpert und erachte das als ueberfluessig.
mutig
Hmm.
Der Aesthetik wegen wuerde ich das gern entfernen. Gibt es da irgendwas schlimmes zu erwarten bzw. setzt irgendwas zwingend darauf auf?
Mal im Ernst, über das alternatives-System wird z.B. die Wahl des Windowmanager geregelt oder auch welcher Java-Compiler benutzt wird und noch eine Menge mehr.
Hmm, das mag ja eine gute Idee sein, aber wenn ich einen Job machen will, dann ueberlege ich mir, welche Tools ich dafuer nehmen will; fuer den Rest gibt es Configs bzw. Dotfiles. Wenn ich Software schreibe, die andere voraussetzt, dann weise ich darauf hin und ueberlege mir ggfs. Default-Werte. So richtig ist mir der Sinn der Sache noch nicht klar.
Wenn ich jetzt also ein Programm veroeffentliche, dass einen Editor braucht, dann patcht das ein Debian-Maintainer u.U. so, dass auf /usr/bin/editor zurueckgefallen wird, falls $EDITOR oder $VISUAL nicht da ist; d.h. mein Default ist weg. Ich weiss noch nicht, ob ich das gut finden soll. Ausserdem stoesst man damit vielleicht ja auch Usern vor den Kopf, die das System nicht kennen, wenn man dann ploetzlich etwas aendert etwas geaendert wird und der Admin nichts davon weiss.
man update-alternatives hilft dir weiter
Da steht nur, wie es funktioniert: Gruppierungen, Prioritaeten, etc. Wenn ich es mir auf der Zunge zergehen lasse, dann ist doch recht hoher Aufwand fuer IMHO wenig Nutzen.
Ausserdem ist das bei mir inkonsistent und unuebersichtlich, weshalb es mich ja stoert. Zum Beispiel ist nur OpenSSH installiert und es gibt symlinks unter /etc/alternatives. Ich habe mehrere Shells und diverse makes installiert, wofuer es keine Symlinks gibt. Liegt das dann an den Maintainern? Was macht das Alternatives-System, wenn der Name eines Tools == Name des Tasks ist (im Beispiel von make)?
Ich hatte ja irgendwie gehofft, dass mir jemand verraten kann, was genau nicht mehr laeuft, wenn ich das alles entferne. Ich werds wohl einfach mal tun und abwarten, was passiert.
bye, Rocco
Am 22. Januar 2003 schrieb Rocco Rutte:
Wenn ich jetzt also ein Programm veroeffentliche, dass einen Editor braucht, dann patcht das ein Debian-Maintainer u.U. so, dass auf /usr/bin/editor zurueckgefallen wird, falls $EDITOR oder $VISUAL nicht da ist; d.h. mein Default ist weg.
Eigentlich ist das doch hier offensichtlich - es gibt in Debian wahrscheinlich Dutzende Editoren und darin verschiedene Versionen von vi, emacs und xemacs. Um wenigstens einen als /usr/bin/{editor,vi,emacs,xemacs} ansprechen zu können, gibt es den Alternatives-Mechanismus, der auch dafür sorgt, das nach dem Deinstallieren eines Pakets die Symlinks u. U. wieder korrigiert werden. Das was der Systemadministrator festlegt, wird allerdings niemals automatisch geändert.
Ich habe mehrere Shells und diverse makes installiert, wofuer es keine Symlinks gibt. Liegt das dann an den Maintainern?
Wenn Pakete verschiedener Maintainer das Alternatives-System nutzen sollen, müssen sich diese Maintainer natürlich erst abstimmen. Möglicherweise ist einfach das der Grund. Oder es liegt schlicht daran, das unter Debian viele Sachen das GNU make als make erwarten und man deshalb aus 'Kompatibilitätsgründen' keine Alternatives hier einsetzt.
Bei den Shells hast du übrigens nicht recht. Die csh beispielsweise wird über Alternatives verwaltet.
Torsten
Hi,
* Torsten Werner [03-01-23 08:45:05 +0100] wrote:
Am 22. Januar 2003 schrieb Rocco Rutte:
Eigentlich ist das doch hier offensichtlich - es gibt in Debian wahrscheinlich Dutzende Editoren und darin verschiedene Versionen von vi, emacs und xemacs. Um wenigstens einen als /usr/bin/{editor,vi,emacs,xemacs} ansprechen zu können,
Das ist bei Editoren ja auch gut und schoen. Wenn ich so recht drueber nachdenke, ist das sogar gut, wenn $DAU sich die Configs in $HOME kaputt macht und andere Software (crontab -e, z.B.) trotzdem noch tut. Aber 'was mir noch Kopfzerbrechen macht, sind Kommandozeilen-Tools und dort speziell die Kommandozeilen-Optionen.
Beispiel: es gibt '/usr/bin/mp3-decoder'. Jeder Kommandozeilen-Decoder mag seine eigenen Optionen haben; und woher weiss jetzt Paket XY, was /usr/bin/mp3-decoder nutzt, welche Optionen erlaubt sind (neben dem puren Dateinamen; aber es ist ja nicht gesichert, dass der ohne Switch akzeptiert wird; oder Streams, etc.)? Diskutieren dann die Maintainer aller mp3- Decoder und kommen zu dem Ergebnis, dass sich die gebraeuchlichsten Optionen so aehnlich sind, dass man das ruhigen Gewissens vertreten kann?
Ich habe mehrere Shells und diverse makes installiert, wofuer es keine Symlinks gibt. Liegt das dann an den Maintainern?
Wenn Pakete verschiedener Maintainer das Alternatives-System nutzen sollen, müssen sich diese Maintainer natürlich erst abstimmen. Möglicherweise ist einfach das der Grund. Oder es liegt schlicht daran, das unter Debian viele Sachen das GNU make als make erwarten und man deshalb aus 'Kompatibilitätsgründen' keine Alternatives hier einsetzt.
Klingt plausibel, obwohl nicht 100% konsistent. Richtig praktisch waeren Alternatives allerdings auch fuer die MTAs und deren Einlieferungskommandos (meistens ein sendmail- benanntes Binary). Zumindest postfix, exim und sendmail nehmen die gleichen Optionen, qmail weiss ich nicht. Aber wahrscheinlich ist Mail zu wichtig, als dass man hier etwas riskieren will.
Bei den Shells hast du übrigens nicht recht. Die csh beispielsweise wird über Alternatives verwaltet.
Stimmt, jetzt wo du es sagst...
bye, Rocco
Hallo Rocco,
On Thu, Jan 23, 2003 at 10:20:03AM +0100, Rocco Rutte wrote:
Klingt plausibel, obwohl nicht 100% konsistent. Richtig praktisch waeren Alternatives allerdings auch fuer die MTAs und deren Einlieferungskommandos (meistens ein sendmail- benanntes Binary). Zumindest postfix, exim und sendmail nehmen die gleichen Optionen, qmail weiss ich nicht. Aber wahrscheinlich ist Mail zu wichtig, als dass man hier etwas riskieren will.
Hast Du schonmal ein System gesehen, wo mehrere verschiedene MTAs installiert und lauffaehig waren (von virtuellen Servern mal abgesehen)?
Bei den Shells hast du ?brigens nicht recht. Die csh beispielsweise wird ?ber Alternatives verwaltet.
Stimmt, jetzt wo du es sagst...
*csh != {b*,}sh
[eigentlich muesste man da regexps nehmen]
Holger
On Thu, 23 Jan 2003 10:20:03 +0100, Rocco Rutte wrote:
Beispiel: es gibt '/usr/bin/mp3-decoder'. Jeder Kommandozeilen-Decoder mag seine eigenen Optionen haben; und woher weiss jetzt Paket XY, was /usr/bin/mp3-decoder nutzt, welche Optionen erlaubt sind (neben dem puren Dateinamen; aber es ist ja nicht gesichert, dass der ohne Switch akzeptiert wird; oder Streams, etc.)?
Wenn du nicht nur den Kommandonamen benötigst sondern Features, in denen sich die Altenativen voneinander unterscheiden, musst du eben den wirklichen Programmnamen angeben. Wenn du als z.B. in einem Skript die GNU-Extensions von gawk nutzt, darfst du nicht awk hinschreiben, da sich hinter awk auch der mawk verbergen kann.
Diskutieren dann die Maintainer aller mp3- Decoder und kommen zu dem Ergebnis, dass sich die gebraeuchlichsten Optionen so aehnlich sind, dass man das ruhigen Gewissens vertreten kann?
Nö.
Ich habe mehrere Shells und diverse makes installiert, wofuer es keine Symlinks gibt. Liegt das dann an den Maintainern?
Über was willst du denn auf sie Shells zugreifen? /bin/shell , was mal die tcsh und mal die bash ist? Sinnlos! Ein /bin/compiler , was mal auf gcc und mal auf eien modula-Compiler zeigt auch.
Bring doch mal einen konkreten Fall, wo du den Mechanismus blöd findest.
Klingt plausibel, obwohl nicht 100% konsistent. Richtig praktisch waeren Alternatives allerdings auch fuer die MTAs und deren Einlieferungskommandos (meistens ein sendmail- benanntes Binary).
Ist bei debian aber so, daß du nur einen MTA installieren kannst. Somit ist /etc/alternatives sinnfrei. Das jeweilige MTA stellt also selbst /usr/sbin/sendmail zur Verfügung. Falls Debian es mal als sinnvoll empfinden wird, mehrere MTAs gleichzeitig zuzulassen, werden diese bestimmt in /etc/alternatives auftauchen.
BTW: Bei NetBSD wird postfix und sendmail parallel installiert und dann so etwa wie bei debians alternatives verlinkt. Das liegt aber am Nichtvorhandensein von Paketen der NetBSD-Basisinstallation. Die hätten sich sonst für genau einen MTA entscheiden müssen.
Reinhard
Hi,
* Reinhard Foerster [03-01-23 20:31:04 +0100] wrote:
On Thu, 23 Jan 2003 10:20:03 +0100, Rocco Rutte wrote:
Wenn du nicht nur den Kommandonamen benötigst sondern Features, in denen sich die Altenativen voneinander unterscheiden, musst du eben den wirklichen Programmnamen angeben.
[...]
Ich habe mehrere Shells und diverse makes installiert, wofuer es keine Symlinks gibt. Liegt das dann an den Maintainern?
Über was willst du denn auf sie Shells zugreifen? /bin/shell , was mal die tcsh und mal die bash ist? Sinnlos! Ein /bin/compiler , was mal auf gcc und mal auf eien modula-Compiler zeigt auch.
Richtig. Das gleiche gilt auch fuer MP3 Decoder, auch wenn es hier nicht wirklich tragisch ist, wenn das eigentliche Tool hinter den Symlinks fehlschlaegt. Es koennte aber rein theoretischer Natur Daten mit mp3 statt {b,g}zip komprimieren, wobei es wieder tragischer waere. Haette, wuerde, koennte,... ich weiss.
Bring doch mal einen konkreten Fall, wo du den Mechanismus blöd findest.
Hmm, ich wollte ja gerade ein _konkretes_ Beispiel wissen, wo Alternatives zum Einsatz kommt. Die Tatsache, dass mir (u.a. hier) niemand eines nennen konnte, ist fuer mich Grund genug, dass nicht richtig zu moegen, weil es ueberfluessig ist. Ich weiss momentan keinen Weg, das System negativ zu nutzen, aber es ist halt noch eine Stelle mehr, auf die ich sicherheitshalber ein Auge werfen muss.
BTW: Bei NetBSD wird postfix und sendmail parallel installiert und dann so etwa wie bei debians alternatives verlinkt. Das liegt aber am Nichtvorhandensein von Paketen der NetBSD-Basisinstallation. Die hätten sich sonst für genau einen MTA entscheiden müssen.
Hmm, unter FreeBSD kann ich so viele MTAs installieren, wie ich will. Wenn man bei der Installation von Postfix den angezeigten Text ignoriert und sendmail per /etc/rc.conf starten laesst, dann laeuft halt sendmail als Daemon. Was mich aber nicht daran hindert, Postfix stattdessen fuer den Transport zu nutzen.
bye, Rocco
* Rocco Rutte wrote:
Hmm, ich wollte ja gerade ein _konkretes_ Beispiel wissen, wo Alternatives zum Einsatz kommt. Die Tatsache, dass mir (u.a. hier) niemand eines nennen konnte, ist fuer mich Grund genug, dass nicht richtig zu moegen,
Einfach falsch deine Argumentation. Torsten hat dir das mit den MTA's auseinander genommen und ich hab einen Hinweis auf die Windowmanager geliefert. Das sind zwei konkrete Beispiele.
weil es ueberfluessig ist. Ich weiss momentan keinen Weg, das System negativ zu nutzen, aber es ist halt noch eine Stelle mehr, auf die ich sicherheitshalber ein Auge werfen muss.
Zeitverschwendung.
Grüße Jan
* Deine Message-ID ist ungueltig
[ ^ Das machen mein Mailer und Editor automatisch; ich kann nichts fuer diesen Hinweis ;-) ]
Hi,
* Jan Rakelmann [03-01-25 12:02:28 +0100] wrote:
- Rocco Rutte wrote:
Hmm, ich wollte ja gerade ein _konkretes_ Beispiel wissen, wo Alternatives zum Einsatz kommt. Die Tatsache, dass mir (u.a. hier) niemand eines nennen konnte, ist fuer mich Grund genug, dass nicht richtig zu moegen,
Einfach falsch deine Argumentation. Torsten hat dir das mit den MTA's auseinander genommen und ich hab einen Hinweis auf die Windowmanager geliefert. Das sind zwei konkrete Beispiele.
Gut, das war dann wohl unklar formuliert. "Paket XY kann auf /usr/bin/editor ausweichen, damit ...". Mir ist klar, dass /usr/bin/editor ein Symlink auf den vom Admin bevorzugten Editor ist, schon klar; mit "konkret" meinte ich genau den Namen irgendeines Paketes XY, dass das wirklich nutzt... und nicht ein konkretes Beispiel, wo Alternatives zum Einsatz kommen _koennten_.
weil es ueberfluessig ist. Ich weiss momentan keinen Weg, das System negativ zu nutzen, aber es ist halt noch eine Stelle mehr, auf die ich sicherheitshalber ein Auge werfen muss.
Zeitverschwendung.
Solange ich davon ausgehen kann, dass die Maintainer alles richtig machen, hast du Recht. Dass aber beispielsweise /etc/alternatives/rcp ein Symlink auf /usr/bin/ssh ist, dass dann wiederum auf /usr/bin/ssh2 verklinkt ist, leuchtet mir ueberhaupt nicht ein (besonders ersterer Link). Und genau sowas kann in die Hose gehen, wenn irgendein Paket jetzt /usr/bin/rcp mit entsprechenden Optionen aufruft.
bye, Rocco
On Sat, 25 Jan 2003 10:36:13 +0100, Rocco Rutte wrote:
Bring doch mal einen konkreten Fall, wo du den Mechanismus blöd findest.
Hmm, ich wollte ja gerade ein _konkretes_ Beispiel wissen, wo Alternatives zum Einsatz kommt. Die Tatsache, dass mir (u.a. hier) niemand eines nennen konnte, ist fuer mich Grund genug, dass nicht richtig zu moegen, weil es ueberfluessig ist.
ls /etc/alternatives
Da sind einige schon auf den erten Blick sinnvolle Dinge dabei. Nimm tclsh:
Entweder erlaubst du nur eine tcl-Version auf dem Rechner (ist bei Debina nicht so) oder du hat einen konflikt, welche version das programm tclsh zur Verfügung stellt, oder du hast gat kein tclsh sondern nur tclsh73, tclsh82 usw. Dann müßt du ohne alternatives in jedem tcl-skript die Versionnummer fest verdrahten ( #!/usr/bin/tclsh73). Das bringt doch nur sinnlose neue Abhängigkeiten ins System.
Alternatives wie "x-terminal-emulator" finde ich für mich nicht sinnvoll, da sie außer auf Debian nirgends existieren, also sowieso nur in einer Debian-only-Umgebung in Skripten verwendet werden können. Sowas mag ich nicht, es stört mich aber auch nicht.
Reinhard
Rocco Rutte s1118644@mail.inf.tu-dresden.de writes:
Hmm, ich wollte ja gerade ein _konkretes_ Beispiel wissen, wo Alternatives zum Einsatz kommt. Die Tatsache, dass mir (u.a. hier) niemand eines nennen konnte, ist fuer mich Grund genug, dass nicht richtig zu moegen, weil es ueberfluessig ist.
Wenn dich das ernsthaft interessiert, nimm mal ein installiertes Debian und schaue dir an, was so in /etc/alternatives steht. Wir müssen dir hier nicht alles vorkauen.
Sven
Am Donnerstag, dem 23. Januar 2003 um 10:20:03, schrieb Rocco Rutte:
Beispiel: es gibt '/usr/bin/mp3-decoder'. Jeder Kommandozeilen-Decoder mag seine eigenen Optionen haben; und woher weiss jetzt Paket XY, was /usr/bin/mp3-decoder nutzt, welche Optionen erlaubt sind (neben dem puren Dateinamen; aber es ist ja nicht gesichert, dass der ohne Switch akzeptiert wird; oder Streams, etc.)?
Alternatives haben natürlich nur Sinn bei Programmen die halbwegs kompatibel zueinander sind. So verstehen sicher die Varianten von x-terminal-emulator die Kernoptionen eines xterm. Wie das bei mp3-decoder aussieht, weiss ich allerdings nicht...
Klingt plausibel, obwohl nicht 100% konsistent. Richtig praktisch waeren Alternatives allerdings auch fuer die MTAs und deren Einlieferungskommandos (meistens ein sendmail- benanntes Binary).
Siehe Holger - mehrere MTAs können unter Debian nicht gleichzeitig installiert werden - und /usr/sbin/sendmail bieten sie wahrscheinlich alle, oder?
Torsten
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Rocco, Liste...
On Wed, 22 Jan 2003 22:18:52 +0100 Rocco Rutte s1118644@mail.inf.tu-dresden.de wrote:
Wenn ich jetzt also ein Programm veroeffentliche, dass einen Editor braucht, dann patcht das ein Debian-Maintainer u.U. so, dass auf /usr/bin/editor zurueckgefallen wird, falls $EDITOR oder $VISUAL nicht da ist; d.h. mein Default ist
In diesem Falle hat das den Vorteil, daß einerseits nicht unbedingt nutzlose Abhängigkeiten eingeführt werden müssen (weil etwa der lokale Nutzer gern mit nvi arbeitet und jetzt vim mitinstallieren muß, nur weil ein bestimmtes Paket keinen 'allgemeinen' vi, sondern explizit einen bestimmten verlangt), und andererseits Programmpakete, die einfach nur "irgendeinen" Editor brauchen, im Zweifelsfall nicht durch die Installation bestimmter Pakete kaputtzukriegen sind (irgendein Editor wird wohl immer installiert sein). Halte ich eigentlich für eine gute Sache...
Cheers, Kris
- -- Für Freiheit von Information, Kommunikation, Software: NEIN zu Softwarepatenten! NEIN zu TCPA! NEIN zu Microsoft! http://fsfeurope.org * http://www.ffii.org * http://www.notcpa.de http://www.debian.org * http://www.gnu.org * http://burnallgifs.org
Hi,
* Kristian Rink [03-01-23 11:32:08 +0100] wrote:
On Wed, 22 Jan 2003 22:18:52 +0100 Rocco Rutte s1118644@mail.inf.tu-dresden.de wrote:
Wenn ich jetzt also ein Programm veroeffentliche, dass einen Editor braucht, dann patcht das ein Debian-Maintainer u.U. so, dass auf /usr/bin/editor zurueckgefallen wird, falls $EDITOR oder $VISUAL nicht da ist; d.h. mein Default ist
In diesem Falle hat das den Vorteil, daß einerseits nicht unbedingt nutzlose Abhängigkeiten eingeführt werden müssen
Naja, die Abhaengigkeiten unter Debian sind fuer manche Pakete ohnehin schon sehr komisch, um es mal vorsichtig auszudruecken. Ich sehe zum Beispiel nicht ein, warum ich libsasl7 und einen MTA fuer mutt brauche (darueber brauchen wir jetzt aber nicht diskutieren). Ich persoenlich definiere ja Abhaengigkeiten nur ueber die dynamisch dazugelinkten Bibliotheken; also nur alles das, um ein Binary zu starten. Ueber alles andere zur Laufzeit benoetigte haette ich gern a) einen Hinweis und b) selbst die Entscheidung, ob ich das wirklich will. Das ist zwar unter Debian moeglich und macht viel mehr Arbeit, aber meistens muss ich das sowieso, wenn mir die Abhaengigkeiten nicht gefallen.
und andererseits Programmpakete, die einfach nur "irgendeinen" Editor brauchen, im Zweifelsfall nicht durch die Installation bestimmter Pakete kaputtzukriegen sind (irgendein Editor wird wohl immer installiert sein). Halte ich eigentlich für eine gute Sache...
Naja, es ist halt die Frage, ob das wirklich Sinn macht. Ich habe auf einem Rechner mutt installiert; und das nur, damit per Cronjob versendete Mails ordentlich formatiert und mit den richtigen Einstellungen bei mir ankommen. Das Debian Packet fuer mutt weist keinen Editor als Abhaengigkeit auf, obwohl die Mehrzahl der Nutzer einen Editor braucht. Es weist aber eine Abhaengigkeit fuer einen MTA auf, weil die Mehrzahl der Nutzer (also nicht alle) einen MTA braucht.
bye, Rocco
* Rocco Rutte wrote:
Naja, es ist halt die Frage, ob das wirklich Sinn macht. Ich habe auf einem Rechner mutt installiert; und das nur, damit per Cronjob versendete Mails ordentlich formatiert und mit den richtigen Einstellungen bei mir ankommen. Das Debian Packet fuer mutt weist keinen Editor als Abhaengigkeit auf,
Weil eine "minimal-vi" bei der Grund-Installation (ca. 70 MB bei Woody) dabei ist.
obwohl die Mehrzahl der Nutzer einen Editor braucht. Es weist aber eine Abhaengigkeit fuer einen MTA auf, weil die Mehrzahl der Nutzer (also nicht alle) einen MTA braucht.
Naklar, die Mails müssen ja auch irgendwie raus. Brieftauben werden nur noch selten benutzt. ;-)
Jan
Hi,
* Jan Rakelmann [03-01-25 12:02:33 +0100] wrote:
- Rocco Rutte wrote:
obwohl die Mehrzahl der Nutzer einen Editor braucht. Es weist aber eine Abhaengigkeit fuer einen MTA auf, weil die Mehrzahl der Nutzer (also nicht alle) einen MTA braucht.
Naklar, die Mails müssen ja auch irgendwie raus.
Naja, aber es gibt durchaus Situationen, wo man keinen MTA zusammen mit mutt installieren will. Dann muss man sich entweder ein Dummy-Packet bauen oder macht alles gleich per Hand. Muss 'mal Telekom-Webseiten studieren, aber es kann sein, dass ich ab 01.03. keinen MTA mehr brauchen werde und trotzdem Mails schreibe (dann wird halt die mutt-Variable $sendmail auf ein Shell-Script umgebogen).
Kurz: Man kann vorzueglich darueber streiten, ob ein "Depends" bei mutt als MTA wirklich noetig ist oder ob das besser nach "Recommends" gehoert. /me ist fuer letzteres, aber darueber brauchen wir hier nicht streiten.
bye, Rocco
Am Samstag, dem 25. Januar 2003 um 10:36:13, schrieb Rocco Rutte:
Das gleiche gilt auch fuer MP3 Decoder, auch wenn es hier nicht wirklich tragisch ist, wenn das eigentliche Tool hinter den Symlinks fehlschlaegt.
Was du mit fehlschlaegt meinst, ist mir nicht klar. Der Grund für mp3-decoder ist scheinbar, dass es 9 verschiedene Versionen gibt, manche für oss, für nas oder für esd und der Admin halt eine Version als Standard über Alternatives festlegen kann. GUI-Frontends zum Abspielen von MP3s können dann /usr/bin/mp3-decoder aufrufen, solange der Benutzer nichts anderes einstellt. Was ist denn daran schlecht? Mir scheint das äusserst nützlich, auch wenn ich selbst lieber xmms benutze, der keine externen Programme zum dekodieren aufruft.
Hmm, ich wollte ja gerade ein _konkretes_ Beispiel wissen, wo Alternatives zum Einsatz kommt.
... Am Samstag, dem 25. Januar 2003 um 13:13:51, schrieb Rocco Rutte:
Dass aber beispielsweise /etc/alternatives/rcp ein Symlink auf /usr/bin/ssh ist, dass dann wiederum auf /usr/bin/ssh2 verklinkt ist, leuchtet mir ueberhaupt nicht ein (besonders ersterer Link).
Hier hast du selbst dein Beispiel gefunden. /usr/bin/rcp arbeitet in deinem Fall also wie scp und ist weitgehend Kommandozeilen-kompatibel zum originalen, aber unsicheren rcp. Zur Not kann man aber trotzdem auf den echten rcp zurück greifen. Das ist doch genau das was man als Admin will, oder? Bessere Beispiele bitte...
Am Samstag, dem 25. Januar 2003 um 13:25:07, schrieb Rocco Rutte:
Naja, aber es gibt durchaus Situationen, wo man keinen MTA zusammen mit mutt installieren will.
Package: ssmtp Provides: mail-transport-agent Depends: libc6 (>= 2.2.4-4), debconf Conflicts: mail-transport-agent Size: 26282 Description: Extremely simple MTA to get mail off the system to a mail hub A secure, effective and simple way of getting mail off a system to your mail hub. It contains no suid-binaries or other dangerous things - no mail spool to poke around in, and no daemons running in the background. Mail is simply forwarded to the configured mailhost. Extremely easy configuration. . WARNING: the above is all it does; it does not receive mail, expand aliases or manage a queue. That belongs on a mail hub with a system administrator.
Dagegen ist
Package: mutt Size: 1301592
fünfzig mal größer. Die Abhängigkeit von mail-transport-agent ist also lächerlich harmlos. Ich verstehe nicht, wieso darauf ständig herumgeritten wird.
Torsten
Hi,
* Torsten Werner [03-01-25 22:22:39 +0100] wrote:
Am Samstag, dem 25. Januar 2003 um 10:36:13, schrieb Rocco Rutte:
GUI-Frontends zum Abspielen von MP3s können dann /usr/bin/mp3-decoder aufrufen, solange der Benutzer nichts anderes einstellt. Was ist denn daran schlecht?
Das muss ja nicht schlecht sein. Aber fuer *mich* ist es oversized. Wenn ich irgendeine Software installiere, die andere zur Laufzeit benoetigt, dann passe ich das an meine Beduerfnisse an. Bevor ich irgendwas neues starte, gucke ich mir das schon an, ohne zu erwarten, dass es out-of-the-box einfach tut. Aber gut, fuer mache Leute mag Alternatives ja sinnvoll sein, aber ich muss es ja nicht moegen und weder habe ich es bisher gebraucht noch habe ich mir jemals gewuenscht sowas zu haben. Und weil es ausserdem Debian spezifisch ist, werde ich glaube auch nicht darauf aufbauen.
Dass aber beispielsweise /etc/alternatives/rcp ein Symlink auf /usr/bin/ssh ist, dass dann wiederum auf /usr/bin/ssh2 verklinkt ist, leuchtet mir ueberhaupt nicht ein (besonders ersterer Link).
Hier hast du selbst dein Beispiel gefunden. /usr/bin/rcp arbeitet in deinem Fall also wie scp und ist weitgehend Kommandozeilen-kompatibel zum originalen,
Sicher, *s*cp. Bei mir geht der Link aber nicht auf *s*cp - was ich erwarte - sondern auf /usr/bin/ssh. Das ist nicht, wie vorher geschrieben ein Symlink auf /usr/bin/ssh2; es gibt aber /etc/alternatives/ssh, was auf /usr/bin/ssh2 zeigt. Da ist irgendwas gruendlich kaputt.
Da ich mit Absicht ja mal den Packet-Cache geloescht hatte, kann ich nichtmehr nachvollziehen, warum das genau so ist. Es kann also auch an meiner Unfaehigkeit liegen, was hier wohl wahrscheinlich ist.
Das ist doch genau das was man als Admin will, oder?
Das kann man so sehen, muss man aber nicht. Wenn ich scp will, nehme ich scp. Wenn ich (oder jemand auf meinem System) rcp nehmen will und ich etwas dagegen habe, dann fliegt das rcp Binary 'raus und manches funktioniert dann halt nicht mehr und muss gefixt werden.
Naja, aber es gibt durchaus Situationen, wo man keinen MTA zusammen mit mutt installieren will.
[...]
Die Abhängigkeit von mail-transport-agent ist also lächerlich harmlos. Ich verstehe nicht, wieso darauf ständig herumgeritten wird.
Weil es einen Mehraufwand bedeutet, wenn man mal keine Transport-Software haben will. Das muss noch nichtmal Platzgruende haben. Und ob es nun ssmtp, Postfix oder ein Sendmail ist, spielt absolut keine Rolle, weil man es eh nicht haben will. Aber wenn andererseits in der Policy steht, dass das der Maintainer einen MTA in Depends: zu schreiben hat, dann nimmt man es entweder hin und macht es gleich per Hand, oder man wechselt die Distribution.
bye, Rocco
Am Sonntag, dem 26. Januar 2003 um 15:52:31, schrieb Rocco Rutte:
Das muss ja nicht schlecht sein. Aber fuer *mich* ist es oversized.
Ein Symlink ist 'oversized'? Aber gleichmal 2 echte MTAs installieren wie FreeBSD, das ist OK? Ich krieg die Krise!
Sicher, *s*cp. Bei mir geht der Link aber nicht auf *s*cp - was ich erwarte - sondern auf /usr/bin/ssh.
Ach so, bekannter und bereits behobener Bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=151666 . Sowas kann jedem mal passieren.
Weil es einen Mehraufwand bedeutet, wenn man mal keine Transport-Software haben will.
Die allermeisten mutter möchten aber einen MTA installiert haben und für die wäre es eine Mehraufwand, wenn kein MTA automatisch installiert wird. Und Debian hat das Ziel, für die meisten Benutzer optimiert zu sein und nicht für eine verschwindend geringe Minderheit, die nicht mal in der Lage ist, konstruktive Kritik zu formulieren. Mach' doch mal einen brauchbaren Vorschlag, was genau wie geändert werden sollte, ohne das die Mehrheit der Debianer Nachteile erleidet!
Ich verstehe Dein Problem nach wie vor nicht, schliesslich kannst du dir dein eigenen mutt oder dein eigenes leeres MTA-Paket bauen. Du hast auch nicht begründet, was an einem installiertem ssmtp schlimm ist. Der verbrauchte minimale Plattenplatz scheint es offensichtlich nicht zu sein.
Torsten
Hi,
* Torsten Werner [03-01-26 18:17:06 +0100] wrote:
Am Sonntag, dem 26. Januar 2003 um 15:52:31, schrieb Rocco Rutte:
Das muss ja nicht schlecht sein. Aber fuer *mich* ist es oversized.
Ein Symlink ist 'oversized'?
Nein, den Alternatives-Mechanismus halte *ich* fuer oversized. Es muss in den Packages verdrahtet werden, wobei sich Maintainer ueber etwaige Problemchen Gedanken machen muessen, es braucht Software, um die Symlinks zu verwalten, etc. Aber wenn andere das System gut finden und der Nutzen den Aufwand rechtfertigt, von mir aus.
Aber gleichmal 2 echte MTAs installieren wie FreeBSD, das ist OK? Ich krieg die Krise!
FreeBSD installiert nicht mehrere MTAs. Wenn man etwas anderes als Sendmail installiert, muss man sendmail entfernen, damit man nicht zwei MTAs hat, wenn man das nicht will. Ausserdem ging es darum, dass ich das theoretisch machen kann, wenn ich es brauche. Um beispielsweise Tests anzustellen, muesste ich unter Debian da schon etwas mehr Handarbeit installieren.
Ach so, bekannter und bereits behobener Bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=151666 . Sowas kann jedem mal passieren.
s.u.
Die allermeisten mutter möchten aber einen MTA installiert haben und für die wäre es eine Mehraufwand, wenn kein MTA automatisch installiert wird. Und Debian hat das Ziel, für die meisten Benutzer optimiert zu sein und nicht für eine verschwindend geringe Minderheit,
Richtig, und genau deshalb habe ich verloren, weil ich die Vorteile des sonst guten Paket-Management-Systems nicht nutzen kann.
die nicht mal in der Lage ist, konstruktive Kritik zu formulieren. Mach' doch mal einen brauchbaren Vorschlag, was genau wie geändert werden sollte, ohne das die Mehrheit der Debianer Nachteile erleidet!
Wie gesagt, ich definiere "Abhaengigkeit" fuer mich als die Abhaengigkeit eines Binaries von dynamisch dazugelinkten Bibliotheken.
1) Man reduziert alle Abhaengigkeiten genau darauf und bringt den apt-* Tools bei, mit einem switch '--minimal' (oder so) sich kommentarlos genau darauf zu beschraenken. Vorteil: Die Mehrheit braucht diesen Switch nicht zu nutzen und ich kann in der Shell ein Alias dafuer machen.
2) "Recommends" wird genau auf die Software beschraenkt, ohne die ein Programm aus Sicht der Mehrheit nicht benutzt werden kann; fuer mutt also nur der MTA (und evtl. ein Editor, aber der ist eh schon da). Den apt-* Tools wird beigebracht, sich per Default auf "Depends" zu beschraenken und dem User anzuzeigen, was in "Recommends" steht. Und natuerlich fragen, ob diese auch installiert werden sollen. Vorteil: ich kann den Switch aus 1) auch weglassen und fuer jeden Einzelfall neu entscheiden. Die Mehrheit der Nutzer muss nur einmal mehr 'Y' druecken.
3) Der Rest an Software, die man zusammen mit einem Package benutzen kann, kommt nach "Suggests". Sowas koennte sich ueber apt-* auch per optionalem Switch installieren lassen.
Ich verstehe Dein Problem nach wie vor nicht,
Mein Problem ist, dass ich einen Mechanismus im System habe, auf den ich zusaetzlich bei Software-Installationen ein Auge werfen muss. Und zwar, weil wie in obigem Beispiel auch etwas schief gehen kann.
Du hast auch nicht begründet, was an einem installiertem ssmtp schlimm ist. Der verbrauchte minimale Plattenplatz scheint es offensichtlich nicht zu sein.
Der Plattenplatz ist mir egal. Warum soll ich aber Software installieren, nur damit sie da ist und nicht benutzt wird? Wenn mir der Plattenspeicher egal ist, kann ich auch ein paar Gigabyte Software installieren, die ich nicht benutzen will. Das ist doch kein Problem, doch warum sollte ich das tun?
bye, Rocco
On Sat, 25 Jan 2003 10:48:54 +0100, Rocco Rutte wrote:
Naja, die Abhaengigkeiten unter Debian sind fuer manche Pakete ohnehin schon sehr komisch, um es mal vorsichtig auszudruecken. Ich sehe zum Beispiel nicht ein, warum ich libsasl7 und einen MTA fuer mutt brauche (darueber brauchen wir jetzt aber nicht diskutieren). Ich persoenlich definiere ja Abhaengigkeiten nur ueber die dynamisch dazugelinkten Bibliotheken; also nur alles das, um ein Binary zu starten.
Schreibe einen Bugreport. Wenn du zeigen kannst, dass mutt ohne MTA (mit Debian-Boardmitteln!) "a significant amount of functionality" bieten kann, muesste der MTA nach http://www.debian.org/doc/debian-policy/ch-relationships.html#s7.2 und http://www.debian.org/doc/debian-policy/ch-archive.html#s2.3.4 aus der Depends:-Zeile raus.
Wenn mutt aber ohne MTA nur mit deinem Skript was taugt, hast du keine Chance.
und andererseits Programmpakete, die einfach nur "irgendeinen" Editor brauchen, im Zweifelsfall nicht durch die Installation bestimmter Pakete kaputtzukriegen sind (irgendein Editor wird wohl immer installiert sein). Halte ich eigentlich für eine gute Sache...
Naja, es ist halt die Frage, ob das wirklich Sinn macht. Ich habe auf einem Rechner mutt installiert; und das nur, damit per Cronjob versendete Mails ordentlich formatiert und mit den richtigen Einstellungen bei mir ankommen. Das Debian Packet fuer mutt weist keinen Editor als Abhaengigkeit auf, obwohl die Mehrzahl der Nutzer einen Editor braucht.
Ich tippe mal, dass bei den essential packages schon eins dabei ist, was "editor" anbietet.
Reinhard
Hi,
* Reinhard Foerster [03-01-25 14:53:56 +0100] wrote:
Schreibe einen Bugreport. Wenn du zeigen kannst, dass mutt ohne MTA (mit Debian-Boardmitteln!) "a significant amount of functionality" bieten kann, muesste der MTA nach http://www.debian.org/doc/debian-policy/ch-relationships.html#s7.2 und http://www.debian.org/doc/debian-policy/ch-archive.html#s2.3.4 aus der Depends:-Zeile raus.
Wenn mutt aber ohne MTA nur mit deinem Skript was taugt, hast du keine Chance.
Ich weiss, dass ich absolut in der Minderheit bin, wenn ich mutt ohne MTA installieren _und_ betreiben will. Damit habe ich halt verloren und muss per Hand nacharbeiten. Da ist es besonders schade, dass apt-get mir immer alles installieren will. Libsasl kommt zusammen mit POP3-/IMAP-Support ins Boot, und da ich weder POP3 noch IMAP brauche, dafuer aber andere Patches, muss ich so oder so selber bauen. Deshalb sind mir die Dependencies in dem Fall mehr oder minder egal.
bye, Rocco
Rocco Rutte s1118644@mail.inf.tu-dresden.de writes:
ich bin bei Backups ueber /etc/alternatives unter Debian gestolpert und erachte das als ueberfluessig. Der Aesthetik wegen wuerde ich das gern entfernen.
Dein ästhetisches Problem.
Gibt es da irgendwas schlimmes zu erwarten bzw. setzt irgendwas zwingend darauf auf?
Du mußt nur die Symlinks finden, die dieses Verzeichnis traversieren. Diese würden dann nicht gehen. Es gibt z.B. in /usr/bin/ solche Symlinks.
Also an deiner Stelle würde ich die Idee nicht realisieren.
Sven
lug-dd@mailman.schlittermann.de
-
Holger Dietze -
Jan Rakelmann -
Kristian Rink -
Reinhard Foerster -
Rocco Rutte -
Sven Rudolph -
Torsten Werner