[geschlossen] tlmgr: command not found

[Klaus82]

Hi,
ich hoffe es ist das richtige Unterforum, dass latex als Textprogramm durchgeht.

Ich habe gerade auf meinem neu eingerichteten Debian 6 latex installiert

Code: Alles auswählen

sudo apt-get install texlive

Beim ersten neuen Kompilieren eines Dokumentes fehlen gleich ein paar Pakete, also wollte ich die mittels des texlive managers nachinstallieren, aber tlmgr wird nicht gefunden, auch nicht als superuser?

Debian Squeeze verwendet doch texlive 2009 und angeblich sei der texlive manager seit texlive 2008 dabei.

Was mache ich falsch?

Hinzu komm, vielleicht liegt es auch daran, dass ich hier im Netzwerk hänge und deswegen scheinbar auch Probleme habe, da nicht alles 'mir gehört'.
Ich wollte z.B. auch texlive 2011 von CTAN installieren, das Skript ist aber daran gescheitert, dass es nicht in /usr/local schreiben darf?
Obwohl ich es als sudo ausgeführt habe.

Gruß,
Klaus.

[Natureshadow]

Hi,

http://lists.debian.org/debian-tex-main ... 00425.html

Was dein /usr/local angeht: /usr ist bestimmt read-only gemountet, wie das in Netzwerken üblich ist.

Schau dir mal die Ausgabe von mount an.

-nik

[Klaus82]

Was dein /usr/local angeht: /usr ist bestimmt read-only gemountet, wie das in Netzwerken üblich ist.

Schau dir mal die Ausgabe von mount an.

Äh, ja.

Ich habe es einfach mal in die Konsole mount eingegeben und da steht jetzt einiges.

Wie hilft mir das weiter?

EDIT:

http://lists.debian.org/debian-tex-main ... 00425.html

Aaaaaah, danke. Ich verstehe.
Ich habe jetzt z.B. einfach

Code: Alles auswählen

sudo apt-get install biblatex 

eingegeben und das hat scheinbar funktioniert!
Jetzt nur nicht den texhash vergessen.

Gruß,
Klaus.

[Natureshadow]

Ich habe es einfach mal in die Konsole mount eingegeben und da steht jetzt einiges.

Wie hilft mir das weiter?

Poste es bitte mal .

[Klaus82]

Ich habe es einfach mal in die Konsole mount eingegeben und da steht jetzt einiges.
Wie hilft mir das weiter?

Poste es bitte mal .

Äh, bei allem Respekt, ist das dann kein Sicherheitsrisiko? Weiß ja nicht im Detail was da alles drinsteht.

Ich hatte hatte nochmal in meinem alten LaTeX Thread geschaut. Kann ich nicht einfach mit

Code: Alles auswählen

sudo chown -R <NAME>.users /usr/local

das Verzeichnis zu meinem Eigentum machen, sodass die Installation von Texlive gehen sollte, weil er dann in /usr/local reinschreiben darf?

Viele Grüße,
Klaus.

[Cae]

Äh, bei allem Respekt, ist das dann kein Sicherheitsrisiko? Weiß ja nicht im Detail was da alles drinsteht.

Nö. Falls darin ein -o passwd=foo vorkommen sollte, würde ich erwarten, dass der User es selbst zensieren kann. Das könnte bei smbmount vorkommen, halte ich aber für unwahrscheinlich (ich verwende hier kein smb*). Sonst ist der mount-Output unkritisch, hier der von meiner Kiste:

Code: Alles auswählen

% mount
rootfs / rootfs rw 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
udev /dev devtmpfs rw,relatime,size=4059508k,nr_inodes=1014877,mode=755 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /run tmpfs rw,nosuid,noexec,relatime,size=819804k,mode=755 0 0
/dev/disk/by-uuid/86d17b8d-6697-4812-a48e-2a616d84e9db / ext4 rw,relatime,errors=remount-ro,user_xattr,barrier=1,data=ordered 0 0
tmpfs /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k 0 0
tmpfs /tmp tmpfs rw,nosuid,nodev,relatime,size=1639608k 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /run/shm tmpfs rw,nosuid,nodev,relatime,size=1639608k 0 0
/dev/md1 /media/150stripe ext4 rw,relatime,user_xattr,barrier=1,stripe=256,data=ordered 0 0
fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0

Was kann man da rauslesen? Ich verwende wohl hauptsächlich ext4, die UUID von / wird zwar hier veröffentlicht, ist aber nur lokal relevant. Es gibt einen Haufen tmpfs' und offensichtlich setze ich auch FUSE ein (für sshfs). md1 legt nahe, dass es auch ein md0 geben könnte (richtig, das ist /, RAID1 (Hinweis evtl. data=ordered?)), es selbst scheint 150 GB groß und im RAID0-Modus, also gestript, zu sein (auch richtig). Und sonst?
Exkurs Ende.

Dein Vorschlag, /usr/local/* rekursiv einem User zuzuweisen, ist schon eher ein gigantisches Sicherheitsrisiko, weil ein einziger Benutzer plötzlich systemweite dauerhafte Änderungen macht und zudem evtl. vorhandene Zugriffsrechte kaputt gehen.

Gruß Cae

[owl102]

Was mache ich falsch?

Dein Fehler: Du hast "sudo apt-get install texlive" eingegeben.

IMHO ist es grober Unfug, texlive in eine "stable" Distribution wie Debian Squeeze mit aufzunehmen und um den tlmgr zu kastrieren. TeXlive ist jedes Jahr nur ein Snapshot, nicht mehr und nicht weniger, mit "stable" hat das rein gar nichts zu tun, das ist quasi ein Snapshot von "unstable" wenn nicht gar "experimental". (Jeder kann nach CTAN abkippen was er will.) Und wenn ich dummerweise einen Tag vor dem "Freeze" von TeXlive einen dicken Bug in eines meiner LaTeX-Pakete eingebaut habe, dann ist die Version dieses Paketes in TeXlive (ohne tlmgr, also ohne Update-Möglichkeit) nicht zu gebrauchen. Leider meinen viele (La)TeX-Paketautoren, vor dem Freeze von TeXlive noch 'mal eben schnell eine neue Version nach CTAN zu packen...

Das TeXlive bei Debian (was BTW auch noch um Jahre veraltet ist) ist also nur zu gebrauchen, wenn man mit LaTeX ein paar Briefe schreibt oder alte Dokumente übersetzen möchte, oder Dokumente neu schreibt, die man nach dem gleichen Schema wie alte Dokumente schreibt. Möchte man hingegen richtig neue Dokumente verfassen, wie z.B. eine Magister- oder Doktorarbeit, und dabei ggf. auch LaTeX-Pakete verwenden, die man zuvor nicht verwendet hat, ist es IMHO unbrauchbar. Alle Hilfestellungen und Threads in den TeX-Foren beziehen sich immer auf aktuelle Paketversionen. (Fast) alle, die dort helfend unterwegs sind, haben ein akt. MikTeX (für Windows) oder TeXlive mit tlmgr. Ein manuelles Updaten von Paketen ist in der Praxis nicht immer möglich - weil ggf. Abhängigkeiten zu anderen Paketen vorhanden sind, die dann auch aktualisiert werden müssen etc.

Und möchte man gar ConTeXt verwenden, ist die Version von TeXlive aus dem Debian-Repository sowieso indiskutabel.

Also: Gehe direkt nach http://www.tug.org/texlive/. Gehe nicht über apt-get.

Siehe auch: http://tex.stackexchange.com/questions/ ... on-to-work

Ich wollte z.B. auch texlive 2011 von CTAN installieren, das Skript ist aber daran gescheitert, dass es nicht in /usr/local schreiben darf?

Dann installiere dir TeXlive eben nach /home/xxx/texlive/...

[catdog2]

Das TeXlive bei Debian (was BTW auch noch um Jahre veraltet ist)

wheezy (testing) (tex): TeX Live: Eine anständige Auswahl der TeX-Live-Pakete
2012.20120516-1: all

Dass du in stable nicht immer die aktuellsten Versionen von allem hast ist klar oder?

das Verzeichnis zu meinem Eigentum machen, sodass die Installation von Texlive gehen sollte, weil er dann in /usr/local reinschreiben darf?

Schlechte Idee.

sudo apt-get install texlive

Wenn du alles haben wolltest müsstest du texlive-full nehmen. Ansonsten musst du eben z.B. mit apt-file das passende fehlende Paket finden.

Dein Fehler: Du hast "sudo apt-get install texlive" eingegeben.

Ja das sudo ist komisch wir sind hier ja nicht bei Ubuntu.

TeXlive ist jedes Jahr nur ein Snapshot, nicht mehr und nicht weniger, mit "stable" hat das rein gar nichts zu tun, das ist quasi ein Snapshot von "unstable" wenn nicht gar "experimental".

Dir ist klar was das stable in Debian stable bedeutet? Die Qualität der Software ist halt dadurch beschränkt was Upstream geliefert wird.

Also: Gehe direkt nach http://www.tug.org/texlive/. Gehe nicht über apt-get.

Hab ich auch mal gemacht eben weil ich mal eine neuere Version brauchte, naja das install script könnte besser sein.

Dann installiere dir TeXlive eben nach /home/xxx/texlive/...

Unterhalb von /usr würde ich diesen Bastelpaketmanager eh nicht schreiben lassen.

Und wenn ich dummerweise einen Tag vor dem "Freeze" von TeXlive einen dicken Bug in eines meiner LaTeX-Pakete eingebaut habe, dann ist die Version dieses Paketes in TeXlive (ohne tlmgr, also ohne Update-Möglichkeit) nicht zu gebrauchen.

Bugreport?

[owl102]

Dass du in stable nicht immer die aktuellsten Versionen von allem hast ist klar oder?

Ja, aber ein TeXlive 2009 ist IMHO auch für Squeeze-Verhältnisse schon angekalkt, AFAIK gab es beim Freeze von testing schon recht lange TeXlive 2010. Und um brauchbaren Support von der TeX-Community zu bekommen, ist es deutlich zu alt.

Dir ist klar was das stable in Debian stable bedeutet?

Ja. Wenn jemand eine gänzlich neue (völlig ungetestete) Version eines Debian-Paketes bastelt, landet die bestimmt nicht einen Tag später im Freeze von "testing" und somit anschließend in "stable". Bei TeXlive ist dies aber genau so (zumindest, was LaTeX-Pakete etc. angeht), es ist ein Snapshot, der für Debian auch noch festzementiert wird, d.h. nicht einmal Bugfixes bekommt man.

Die Qualität der Software ist halt dadurch beschränkt was Upstream geliefert wird.

Natürlich. Genau das ist doch aber hier das Problem, man bekommt einen in der Qualität beschränkten, aber trotzdem festzementierten Stand von Frühling 2009.

Bugreport?

Das Paket wird dann von mir gefixt und nach CTAN hochgeladen. Und die Debian-Anwender müssen 1-4 Jahre auf den Bugfix warten, denn nur alle Jubeljahre wird TeXlive in Debian aktualisiert.

[Klaus82]

Das TeXlive bei Debian (was BTW auch noch um Jahre veraltet ist) ist also nur zu gebrauchen, wenn man mit LaTeX ein paar Briefe schreibt oder alte Dokumente übersetzen möchte, oder Dokumente neu schreibt, die man nach dem gleichen Schema wie alte Dokumente schreibt.

Genau!! So sehe ich das auch, doch irgendwie stoße ich in meinem Büro da auf taube Ohren bzw. höre Argumente wie "Also mir reicht das texlive von Debian, was machst du denn so abgefahrenes, dass du immer die aktuellste Version benötigst?"

Ich wollte z.B. auch texlive 2011 von CTAN installieren, das Skript ist aber daran gescheitert, dass es nicht in /usr/local schreiben darf?

Dann installiere dir TeXlive eben nach /home/xxx/texlive/...

Jap, auf die Idee kam ich dann auch irgendwann und werde es nächste Woche nochmal probieren. Letzten Freitag ist es daran gescheitert, dass die Verbindung scheinbar so schlecht war, dass der PC selbst für die Medium Installation nicht in die pushen kam. Sind nur ca. 600 Pakete und allein für 100 Pakete hatte er eine gute Stunde gebraucht. Da hatte ich dann schließlich abgebrochen und bin ins Wochenende.


Aber nochmal was anders, zu diesen Zugriffsrechten:
Ich habe jetzt irgendwo (in der manpage von ls?) gelesen, dass es von den Zugriffsrechten abhängt, ob man bei squeeze die Verzeichnisse farbig angezeigt bekommt oder nicht. Zu Hause bekomme ich alle Verzeichnisse bei ls farbig angezeigt, allerdings nicht auf der Arbeit.
Jetzt hatte ich einen Kollegen nach dem Update murmeln hören "Na immerhin sind jetzt die Verzeichnisse farbig..." Heißt das, dass er und ich verschiedene Zugriffsrechte haben? Obwohl wir beide 'nur' User in dem Netzwerk sind?

Gruß,
Klaus.

[owl102]

Letzten Freitag ist es daran gescheitert, dass die Verbindung scheinbar so schlecht war, dass der PC selbst für die Medium Installation nicht in die pushen kam. Sind nur ca. 600 Pakete und allein für 100 Pakete hatte er eine gute Stunde gebraucht.

Das Problem ist leider nicht unbekannt. Die Installation verwendet einen CTAN-Spiegelserver, aber die sind von sehr unterschiedlicher Qualität, was die Erreichbarkeit und die Bandbreite angeht.

Abhilfe: Dem Installationsskript explizit einen CTAN-Spiegelserver vorgeben, z.B. einen einer deutschen FH oder Uni.

Siehe auch: http://www.tug.org/texlive/acquire-netinstall.html

... the generic mirror.ctan.org url which autoredirects to a CTAN mirror that should be reasonably nearby and reasonably up to date. However, perfect synchronization is not possible; if you have troubles following the links, your best bet is to choose explicitly from the list of CTAN mirrors.

und Hilfstext des Installer-Scripts:

The default is to pick a mirror automatically, using
http://mirror.ctan.org/systems/texlive/tlnet; the chosen mirror is
used for the entire download.

...

For example,
you could choose a particular CTAN mirror with something like this:

-repository http://ctan.example.org/its/ctan/dir/sy ... live/tlnet

Of course a real hostname and its particular top-level CTAN path
have to be specified. The list of CTAN mirrors is available at
http://ctan.org/mirrors.

[Klaus82]

Aaaah,
ich bedanke mich herzlich.

Ich werde von meinem (hoffentlich) Erfolg berichten.

Viele Grüße,
Klaus.

[Natureshadow]

Ich habe jetzt irgendwo (in der manpage von ls?) gelesen, dass es von den Zugriffsrechten abhängt, ob man bei squeeze die Verzeichnisse farbig angezeigt bekommt oder nicht. Zu Hause bekomme ich alle Verzeichnisse bei ls farbig angezeigt, allerdings nicht auf der Arbeit.

Das ist Humbug. Ja, ls kann Verzeichnisse und Dateien abhängig von Rechten einfärben. Nein, das ist nicht die sinnvolle Möglichkeit, Zugriffsrechte zu erkennen. Die Zugriffsrechte sowie Besitzer und Gruppe stehen in der AUsgabe von ls -l bzw. in der von stat.

Jetzt hatte ich einen Kollegen nach dem Update murmeln hören "Na immerhin sind jetzt die Verzeichnisse farbig..." Heißt das, dass er und ich verschiedene Zugriffsrechte haben? Obwohl wir beide 'nur' User in dem Netzwerk sind?

Nein, das heißt nur, dass er vorher nicht in der Lage war, eine simple Einstellung vorzunehmen.

Zeig uns doch bitte endlich mal deine mount-Optionen!

[owl102]

Zusatz zu meinem letzten Beitrag:

Gerade noch in den Optionen von install-tl gefunden:

-select-repository

This option allows manual selection of a mirror from the current list of
active CTAN mirrors. This option is supported in all installer modes
(text, wizard, perltk), and will also offer to install from local media
if available, or from a repository specified on the command line (see
above). It's useful when the (default) automatic redirection does not
choose a good host for you.

[Klaus82]

Zeig uns doch bitte endlich mal deine mount-Optionen!

Alles klar, am Montag dann, wenn ich wieder auf der Arbeit bin.

Viele Grüße,
Klaus.

[Klaus82]

Hi,

also hier der Inhalt von mount

Code: Alles auswählen

/dev/sda9 on / type ext3 (rw,errors=remount-ro)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
fusectl on /sys/fs/fuse/connections type fusectl (rw)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)
<SERVERNAME>:/home on /var/autofs/home/home type nfs (rw,nfsv4,soft,intr,rsize=4096,wsize=4096,sloppy,addr=<ZAHLEN>)
/dev/sdb1 on /media/B4D5-C41D type vfat (rw,nosuid,nodev,uhelper=udisks,uid=4790,gid=4000,shortname=mixed,dmask=0077,utf8=1,showexec,flush)

Ich habe mal den Servernamen und die Adresse herausgenommen.

Aber nochmal zu texlive, mich wundert das einfach mehr und mehr. Wo habe ich denn jetzt als User im Netzwerk Rechte und wo nicht?
Bisher habe ich das so verstanden, dass ich mit sudo ein Programm installieren kann. Kurioser Weise geht das nicht bei texlive, dass in /usr/local schreiben möchte.

Allerdings habe ich jetzt als Zielverzeichnis mein home-Verzeichnis angegeben und darin kann ich komplett ohne sudo arbeiten? Also zum Start der heruntergeladenen Installationsdatei musste ich kein sudo davorsetzen. Und scheinbar funktioniert jetzt auch das Miniskript sutlmgr nicht wie vorgesehen, weil ich keinen sudo davor benötigt, d.h. ich gebe stets nur tlmgr -gui ein.

Jetzt kriege ich nur diesen dummen Fehler beim kompieleren:

Code: Alles auswählen

! LaTeX Error: File `l3toks.sty' not found.

Ich habe ein wenig gegoogelt und z.B. dann auch mittels tlmgr l3kernel installiert und anschließend einen texhash ausgeführt ... aber es bringt nix!

Gruß,
Klaus.

[Natureshadow]

Der Zweck von sudo ist nicht, ein Programm zu installieren, sondern root-Rechte zu bekommen!

[Klaus82]

Der Zweck von sudo ist nicht, ein Programm zu installieren, sondern root-Rechte zu bekommen!

Jo,
so wie ich das gelernt habe steht sudo für substitude user and do, und standardmäßig ist der 'ersetzte' user eben root.

Um also ein Programm zu installieren benötige ich kurz root Rechte - also muss ich die Installtion mit sudo ausführen, kurz zusammengefasst.

Gruß,
Klaus.

[Natureshadow]

Kurz zusammengefasst hast du darüber oben aber großes Unwissen geäußert. Du wundertest dich schließlich, dass du für die Installation in $HOME kein sudo benutzen musst. Mit dem Grundwissen über sudo stellt sich die Frage hiernach nicht.

[Klaus82]

Du wundertest dich schließlich, dass du für die Installation in $HOME kein sudo benutzen musst. Mit dem Grundwissen über sudo stellt sich die Frage hiernach nicht.

Tatsächlich wundert mich da so einiges, dass ich nicht recht verstehe.

Wo ist denn jetzt der Unterschied, ob ich ohne sudo in mein Home Verzeichnis etwas installieren kann oder mittels sudo den Paketmanager aktiviere?
Jetzt ist natürlich die Frage: Unterschied bezüglich was?

In beiden Fällen kann ich etwas installieren, einmal weil es scheinbar mein Homeverzeichnis ist und das andere Mal, weil ich scheinbar in der Gruppe sudo eingetragen bin?

Ich habe noch nicht ganz verstanden wozu diese sudo Abfrage dient, gerade wenn ich jetzt zu Hause an meinen persönlichen PC denke. Es ist mein PC, es ist mein Account - wozu dann die sudo Abfrage?
Bisher habe ich nur Argumente gehört, dass man dadurch noch einmal inne halten soll, um darüber nachzudenken. Okay, sei es drum.

Vielleicht kommt auch hinzu, dass es historisch gewachsen ist, weil scheinbar Linux nie für einen persönlichen Gebrauch konzipiert wurde, sondern dass mehrere user an einem PC arbeiten (weil damals nicht vorstellbar, dass jeder einen PC hat).

Also selbst wenn ich von meinem persönlichen PC zu Hause rede, habe ich scheinbar einfach nur einen Account darauf, wenn man es so nennen möchte.

Und jetzt im Netzwerk wird das ganze scheinbar nochmal komplexer. Nicht nur, dass ich mit sudo ein Programm installieren kann und dadurch kurz root Rechte erhalte [1], nein diese root Rechte müssen ja auch wieder beschnitten sein.
Es muss dazu ausreichen, dass ich ein Programm selbst installieren kann, dass nicht jedes Mal der Admin was machen muss, aber es darf nicht so weit gehen, dass ich z.B. andere User damit löschen oder sperren kann. Also damit bin ich lokal root - oder wie mag man das nennen?
Also gibt es den großen Käse, root, der alles darf. Dann gibt es sudo, womit ich mich beschränkt lokal als großer Käse aufspielen kann und scheinbar das Homeverzeichnis, in dem ich eh alles darf?

Gruß,
Klaus.

[1] Was sind denn root Rechte auf einem privaten PC? Komische Bezeichnung.

[Natureshadow]

Wenn du sudo ausführen kannst, bist du Admin auf dem System.

Bei deinen Ausführungen denke ich durchgehend nur: "WTF? Windows 98 ..." .

Du sollst im Alltagsgebrauch keine privilegierten Rechte haben!

Denk doch einfach mal dadran, dass jeder Prozess, der in deinem Kontext läuft, dieselben Rechte hat wie du. Willst du, dass dein Webbrowser root-Rechte hat?

Das zu erklären, sprengt den Rahmen dieses Threads.

-nik

[owl102]

Allerdings habe ich jetzt als Zielverzeichnis mein home-Verzeichnis angegeben und darin kann ich komplett ohne sudo arbeiten?

Du kannst nicht nur, du solltest es sogar. Denn ansonsten würden die Dateien (in deinem home-Verzeichnis) mit root als Besitzer der Dateien angelegt werden. Ergo: Wenn du TeXlive (oder was-auch-immer) in deinem home-Verzeichnis installierst, solltest du dies stets unter deinem regulären Benutzerkonto, also ohne su bzw. sudo, tun.

Ich habe ein wenig gegoogelt und z.B. dann auch mittels tlmgr l3kernel installiert und anschließend einen texhash ausgeführt ... aber es bringt nix!

Du benötigst neben l3kernel auch l3packages.

Mich wundert ein wenig, daß weder l3kernel noch l3packages bei dir installiert war. Mit welchen Optionen hast du TeXlive installiert? (Ich selber nehme ganz faul einfach immer das Komplettpaket, aber alle Sprachen außer Deutsch/Englisch wähle ich ab, ansonsten dauert mir die Installation doch zu lange.)

Ansonsten würde ich mal in die Log-Datei deines LaTeX-Dokumentes schauen, von wo überhaupt welche Dateien verwendet werden. Vielleicht liegt da noch ein halbes TeXlive im /usr oder /usr/local-Teil herum? Und wie ist $PATH gesetzt, kommt das TeXlive in deinem Verzeichnis vor /usr/bin und /usr/local/bin?

[owl102]

Bei deinen Ausführungen denke ich durchgehend nur: "WTF? Windows 98 ..." .

Leider hat Microsoft dieses Nichtsicherheitskonzept ja bis einschließlich Windows XP durchgezogen, der bei der Installation angegebene Benutzer wurde auch dort noch mit vollen Adminrechten angelegt. Mit der Folge, daß viele Anwender bei Vista und 7 diesbezüglich überfordert sind. (Ebenso sind viele Anwendungen damit überfordert.) Nachzulesen unter anderem in den (La)TeX-Foren, weil man MikTeX (eine TeX-Distribution für Windows) unter Vista/7 wahlweise als Administrator oder als Anwender installieren kann...

[Klaus82]

Soooo,

ich denke meine Verwirrung hat sich ein wenig gelöst. Ich hatte die ganze Zeit dieses usr Verzeichnis so gelesen wie 'user' und dachte die ganze Zeit eben, dass in /usr/local die Dinge von mir als User lokal auf dem Rechner gespeichert werden.

Jetzt habe ich herausgefunden, dass usr einfach für Unix System Resources steht und /usr/local das Verzeichnis der Paketverwaltung ist.

Also ich verstehe das jetzt so, dass ich zwar mittels sudo die root Rechte erhalte, um den Paketmanager verwenden zu können, der dann in /usr/local reinschreibt. Aber ich kann nicht 'manuell' etwas in /usr/local reinschreiben, selbst wenn ich root Rechte habe.

D.h. in dem Falle von texlive kann ich zwar sudo ./install ausführen, aber dennoch ist es mir nicht erlaubt in /usr/local reinzuschreiben.

Wobei ich mich natürlich gerade frage wieso es dann zu Hause funktioniert?

Und jetzt habe ich wieder das Gleiche Problem mit der GSL, die sich auch in /usr/local hineininstallieren möchte ...

Ach ich checks einfach nicht. Wenn das /usr/local nur über die Paketverwaltung zugänglich ist oder sein sollte, warum installieren sich dann Programme dort hinein? Sicher, weil das Scheinbar das Verzeichnis ist, in das Programme o.ä. kommen ... aber wenn ich dazu keinen Zugang habe.

Ich versteh es nicht...

[owl102]

und /usr/local das Verzeichnis der Paketverwaltung ist.

Nö

Debian-Anwendungen installieren sich in der Regel nach /usr. (Ausnahmen sind natürlich diejenigen, die sich nach /bin oder /sbin oder ... installieren.)

/usr/local ist zum Austoben nach Lust-und-Laune gedacht, hier kann man eigene Scripte und Programme (die man allen Anwendern zur Verfügung stellen möchte) reinkopieren, und auch Programminstallationen, die eben nicht die Paketverwaltung der Distribution (hier: apt, aptitude, synaptic, gdebi, ...) verwenden, sollten sich hier ebenfalls reininstallieren.

Kurzum: Hier landet alles, was zwar systemweit installiert wird, aber eben an der Paketverwaltung der Distribution vorbei installiert werden soll bzw. muß.

Beispiel:

Bei "apt-get install texlive" landet ein TeXlive 2009 in /usr.

Bei "sh ./install-tl" landet ein TeXlive 2011 (in wenigen Tagen: TeXlive 2012) in /usr/local.

Aber ich kann nicht 'manuell' etwas in /usr/local reinschreiben, selbst wenn ich root Rechte habe.

Doch, genau so sollte es ein: Mit root-Rechten kannst du in /usr/local schreiben, ohne root-Rechte (in der Regel) nicht.