Prefix bei Paketen

[DymoTL]

Hallo zusammen.

Ich hab ein kleines Problem mit dem Packagesystem von Debian. Und zwar ist es zwar wirklich toll damit zu arbeiten, jedoch gehoere ich zu den Personen die nicht alle Dateien ueberall verteilt im System haben wollen. Ich bevorzuge es alle Dateien eines Programmes in einem Unterverzeichnis zu haben (oder spricht irgendetwas grundsaetzlich dagegen, das so zu handhaben?)
Bisher habe ich bei den Applikationen bei denen mir das wichtig war die Programme selbst kompiliert.
Ich wuerde aber auch fuer diese gerne die Paketverwaltung benutzen. Das wichtigste ist ja eigentlich nur die moeglichkeit auf den ./configure Befehl einfluss zu nehmen (speziell --prefix).
Ist nur die Frage: WIE?
Ich habe es jetzt mit apt-get source ausprobiert. Da kam ich jedoch zu keinem zufriedenstellendem Ergebniss, da ich auch nicht in der rules Datei rumpfuschen will.

Gibt es nicht einfachere Wege? Oder sicherere Wege als den, die rules-Datei umzuschreiben?

TIA
DymoTL

[nil]

Ich bevorzuge es alle Dateien eines Programmes in einem Unterverzeichnis zu haben (oder spricht irgendetwas grundsaetzlich dagegen, das so zu handhaben?)

Generell spricht natürlich nichts dagegen, nur die Leute haben sich ja mal irgendwann Gedanken darüber gemacht.

Auch wenn Du deine Programme so installierst, die bereits existierende "Unordnung" wirst du nicht loswerden, Du wirst sie eher noch verschlimmbessern.
Mach doch mal z.B.:

Code: Alles auswählen

dpkg -l

und nun such Dir ein beliebiges Paket aus (oder mehrere) und mach:

Code: Alles auswählen

dpkg -L <paketname>

oder suche das Paket zur Datei

Code: Alles auswählen

dpkg -S /ein/pfad/zur/datei

Du wirst sehen, dass,

Configs unter /etc
Dokus unter /usr/share
Programme unter /usr/bin
Variablen unter /var/run
Bibliotheken unter /usr/lib
...

stehen. Ist eben so.


PS.: vielleicht sucht du das: http://klik.atekon.de/

[Joghurt]

(oder spricht irgendetwas grundsaetzlich dagegen, das so zu handhaben?)

Ja. Sobald du einen Server und ein Netzwerk hast, in dem verschiedene Architekturen laufen, kommst du so nicht weiter. Schau dir mal den Linux Filesystem Standard an, da ist vieles beschrieben, warum die Sachen so gehandhabt werden.

Nur ein Beispiel:

Paket foo hat Dateien in /usr/bin, /usr/share und /usr/lib

in /usr/bin sind die Dateien, die direkt ausgeführt werden
In /usr/share sind die Dateien, die sonst noch benötigt werden, aber Architekturunabhängig sind (z.B. Textdateien, Bilder, etc)
in /usr/lib sind libraries, die das Programm benötigt, die Prozessorspezifisch sind.

Nun braucht ein Server z.B. nur ein /usr/share Verzeichnis für alle Rechner freizugeben, und muss nur /usr/bin und /usr/lib für jeden Prozessor einzeln speichern. Desweiteren kann /usr read-only gemountet werden, da man weiss, dass die Dateien nicht verändert werden. Das macht es Viren nochmal schwerer, ins System einzudringen.

Die Angewohnheit, alle Dateien in einem Verzeichnis zu haben, kommt noch aus der Zeit, wo Windows oder DOS ein Einzelbenutzersystem war und es kein Paketmanagement gab, so dass man sonst schnell den Überblick verlor.

Mit Paketmanagement können die Dateien ruhig verteilt sein, du kannst jederzeit nachvollziehen, welche Datei wozu gehört.

[gms]

Generell spricht natürlich nichts dagegen, nur die Leute haben sich ja mal irgendwann Gedanken darüber gemacht.

Das ist keine Begründung.
Gerade weil sich die Leute Gedanken gemacht haben, gibt es bei den meisten configure-Scripts die Möglichkeit den "prefix" umzusetzen.

"dpkg -L" bzw. "dpkg -S" würde auch mit den "umgebauten" Debianpaketen funktionieren.

Das Hauptproblem sind die Scripts die "postinst", "preinst", "prerm", "postrm" und "config" die sicherlich keine Rücksicht auf den "prefix" nehmen. Auch die rc Scripts müßten natürlich entsprechend angepaßt werden

Gruß
gms

[DymoTL]

Naja, die Verzeichnisstruktur ist mir schon klar. Nur, aber das liegt vieleicht an meiner unwissenheit, habe ich manchmal das Gefuehl, dass das nicht immer eingehalten wird.
Es kommt oft genug vor, dass ich einfach nicht genau weiss: Wo ist jetzt dieses script zum neustarten des programms oder aehnliches.

Wenn ich dann mit --prefix arbeite, hab ich nen ziemlich eingegrenztes gebiet und kann mir sicher sein, das genau dort all das ist was ich brauche um dieses Programm zu bedienen und zu verwalten. Und da kann mir auch nichts zwischenpfuschen.

Ich hatte eben nur gehofft, eine einfache Methode zu finden um auf source Packages einfluss zu nehmen ohne die Rules zu aendern.

Aber so schlimm ist es ja auch nicht wenn man alles selbst kompiliert

Dieses klik Teil sieht ja ganz nett aus. Waere dann aber schon wieder eine zusaetzliche Software und auf den ersten Blick scheint es nicht so als wuerde es auch nur ein Programm das ich brauche dort geben. Und ich braeuchte X und das laeuft gar nicht auf der Kiste Aber trotzdem Danke. Falls ich irgendwann sogar auf dem Desktop Linux benutzen kann, werde ich das sicher gut gebrauchen koennen.

--
DymoTL

[Joghurt]

Wo ist jetzt dieses script zum neustarten des programms oder aehnliches.

Wie schon geschrieben, dpkg -L paketname

Skripte, die z.B. beim Systemstart aufgerunfen werden, sind immer in /etc/init.d, der Rest in /usr/bin, bzw. /usr/sbin, wenn das Programm nur von root sinnvoll benutzt werden kann.

Versuch erstmal, dich dran zu gewöhnen. Ich hab das System früher auch nicht gemocht, inzwischen finde ich die Windowslösung schlecht!

[gms]

Aber so schlimm ist es ja auch nicht wenn man alles selbst kompiliert

ist sicher nicht schlimm, weniger aufwändig wäre aber der folgende Vorschlag:

du könntest dir Symlinks unter deinem Prefix anlegen:

Code: Alles auswählen

root@gms1:~# pkg=samba
root@gms1:~# prefix=/root/tmp/$pkg
root@gms1:~# rm -rf $prefix
root@gms1:~# dpkg -L $pkg | egrep "/(etc|bin)/" | while read entry; do test -f $entry || continue; dir=`dirname $entry`;mkdir -p $prefix$dir; ln -s $entry $prefix$entry; done
root@gms1:~# find $prefix
/root/tmp/samba/usr/bin/eventlogadm
/root/tmp/samba/usr/bin/smbstatus
/root/tmp/samba/usr/bin/smbcontrol
/root/tmp/samba/usr/bin/profiles
/root/tmp/samba/usr/bin/tdbbackup
/root/tmp/samba/usr/bin/pdbedit
/root/tmp/samba/etc/logrotate.d/samba
/root/tmp/samba/etc/init.d/samba
/root/tmp/samba/etc/cron.daily/samba

Gruß
gms

[yeti]

Desweiteren kann /usr read-only gemountet werden, da man weiss, dass die Dateien nicht verändert werden.

Deswegen schüttle ich über /usr/src immernoch den Kopf...

[yeti]

Wenn ich alle XYZZY-Files in /app/XYZZY/... lege, brauche ich entweder Haufen von Links, um die Executables in ein /bin-artiges Directory, das im PATH auftaucht zu spiegeln oder einen wahnwitzig aufgeblähten PATH (TM), der jedes bin-Dir in jedem App-Subbaum beinhaltet.

Wenn ich Pakete habe, die sich kreuz und quer ergänzen, wird's unübersichtlich. Ich habe also beispielsweise einen Subbaum für Emacs und einen für Python. Wo packe ich nun also python-mode.el hin?

Oder ich habe Emacs und eine Erweiterung zu Emacs. Packe ich die komplett in den Unterbaum von Emacs? Das würde Dein Ansinnen, alle Files eines Paketes in einem eigenen Subbaum zu haben verletzen und so ähnliche Probleme wie den wahnwitzig aufgeblähten PATH (TM) für die Verwaltung der von Emacs nachzuladenden Module erzeugen.

Ich habe mit solchen Ansätzen genug gespielt bei meinen unterschiedlichen Anläufen ein wohlstrukturiertes /opt-Verzeichnis oder gar eine unternehmensspezifische Distribution zu verwalten und muß sagen: Der Weg, den Unix seit Jahren geht, ist verwaltungsmäßig der einzig praxistaugliche der mir vor die Linse kam!

[MartinL25]

auch wenn das vielleicht ketzerisch klingt, aber dann ist Debian vielleicht nicht die richtige Distribution für Dich. Check mal Gobolinux oder Heretix. Gobolinux ist aber wohl ausgereifter.

[DymoTL]

Na vieleicht muss ich wohl wirklich mich einfach mal dazu zwingen mich dran zu gewoehnen.
Denn wenn man genau drueber nachdenkt, so wie es jetzt einige hier erklaert haben, waere es wirklich sinnvoller, es auch so beizubehalten wie es gewuenscht ist.

Die Idee mit den Links finde ich gut. Obwohl das dann auch jede Menge sind.

Dokumentiert ihr euch eigentlich nach jeder Installation die wichtigsten Sachen, oder wie handhabt ihr das?

[DeletedUserReAsG]

Dokumentiert ihr euch eigentlich nach jeder Installation die wichtigsten Sachen, oder wie handhabt ihr das?

Ich persönlich verlasse mich da auf das Paketmanagement.

cu

[I.C.Wiener]

Mal ein Verständnisfrage.
Wenn ich für jedes Programm einen Prefix angebe, liegt ja z.B. das eine in /opt/kopete/bin/kopete und das andere in /opt/psi/bin/psi.
Wie regele ich denn dann meinen $PATH?
Dann müsste ich doch für jedes Programm auch --bindir und so angeben, was dann aber wieder alles in ein zentrales Verzeichnis kopiert.

Oder blick ich grad nicht durch?

MfG

[yeti]

Du symlinkst alles aus /opt/app*/bin nach /bin oder /usr/bin oder /opt/bin und nimmst nur diese Komponente in den PATH auf.

Oder du baust einen wahnwitzig langen Path (TM) a la /opt/app1/bin:/opt/app2/bin:/opt/app3/bin:...:/opt/appN/bin.

Oder Du schreibst ein Filesystem, das die Vereinigung der bin-Dirs der Applikationen On-The-Fly erledigt. (meine bevorzugte Lösung)

Dann wirst Du entdecken, daß es ganz nützlich wäre, das gleiche Problem für die Lib-Verzeichnisse zu lösen, damit Dir /etc/ld.so.conf nicht ellenlang wird.

Du symlinkst alles nach /lib oder /usr/lib oder /opt/lib und nimmst nur diese Komponente in /etc/ld.so.conf auf.

Oder Du schreibst ein Filesystem, das die Vereinigung der lib-Dirs der Applikationen On-The-Fly erledigt. (meine bevorzugte Lösung)

Dann wirst Du entdecken, daß es ganz nützlich wäre, das gleiche Problem für die man-Verzeichnisse zu lösen, damit Dir ein wahnwitzig langer MANPATH (TM) erspart bleibt.

Du symlinkst alles nach /man oder /usr/man oder /usr/share/man oder /opt/man und nimmst nur diese Komponente in den MANPATH auf.

Oder Du schreibst ein Filesystem, das die Vereinigung der man-Dirs der Applikationen On-The-Fly erledigt. (meine bevorzugte Lösung)

Dann wirst Du entdecken, daß es ganz nützlich wäre, das gleiche Problem für die info-Verzeichnisse zu lösen, ...

(((ich hör ja schon auf!!!)))

[gms]

Mal ein Verständnisfrage.
Wenn ich für jedes Programm einen Prefix angebe, liegt ja z.B. das eine in /opt/kopete/bin/kopete und das andere in /opt/psi/bin/psi.
Wie regele ich denn dann meinen $PATH?

Für jedes Programm wird das niemand machen wollen, aber für größere Pakete kann das schon sinnvoll sein und auf anderen Unixplattformen (Solaris, AIX,..) ist das auch durchaus üblich.
Die X11 Pakete werden sogar unter Debian mit einem Prefix versehen "/usr/X11R6". Der Link "/usr/bin/X11" verweist dann auf diese Standardversion, es könnten aber auch zusätzliche Versionen X11Rn installiert werden.

Gruß
gms

[I.C.Wiener]

Ja, ich habe das mit einer Hand voll Programme auch, die in /opt liegen. Hatte mich nur grad gefragt, wie das wohl mit einem ganzen System ausschaut.

Es gibt doch eine Distribution, die für jedes Programm ein eigenes Verzeichnis anlegt. Da finde ich den Weg des LFS aber schöner. Das kann aber auch gewöhnungssache sein.

Im Allgemeinen überlasse ich das alles aber auch dem Paketmanagement.

[gms]

Es gibt doch eine Distribution, die für jedes Programm ein eigenes Verzeichnis anlegt.

man kann ja wirklich alles überteiben

Da finde ich den Weg des LFS aber schöner.

Was hat das mit LFS zu tun ? Meinst du LFS (Linux From Scratch), oder meinst du vielleicht LSB (Linux Standard Base) insbesondere FHS (File Hierarchy Standard) ? Der FHS hat aber in der Tat nicht viel übrig für die "Prefix Installationen"

Gruß
gms

[I.C.Wiener]

"People Can't Memorize Computer Industry Acronyms"

Ich meinte natürlich FHS.

[ToPeG]

Ich habe hier ein kleines Script, das einen OrdnerBaum zu den installierten Paketen aufbaut und die installierten Dateien dort hin linkt.

http://nopaste.debianforum.de/2515

Das ist sicherlich nicht die eleganteste Lösung, da das ganze recht statisch ist.
Wenn man das mit dem Paketmangement sykronisiert würde und das Zusammenfassen der Dateien über FUSE regelte, wäre das sicher eleganter.