Abhängigkeiten von Tarballs ermitteln!

danlei

Well-Known Member
Ich habe mal eine nicht BSD-spezifische Frage:

So manche Forenmitglieder haben ja schon Programme portiert und somit entsprechende Erfahrung im hantieren mit 'rohen' Sourcen.

Wie geht Ihr da beim Ermitteln der Abhängigkeiten vor? Gibt es da ein paar Tips und Tricks, die Ihr mir verraten könnt?

Hintergrund ist, dass ich mir ein LFS aufgesetzt habe. Die Geschichte läuft bis jetzt einwandfrei. Das Basissystem steht, bin online und meine wichtigsten Tools (wer mich kennt weiß: mutt, zsh, vim, screen...) laufen auch schon. Ich nutze keinen Paketmanager, sondern halte mich an den Symlink-Ansatz; dh. ich kompiliere als user (mit ./configure --prefix=/usr) und installiere als root mittels DESTDIR oder prefix nach /usr/local/pkg. Dann mach ich Symlinks nach /usr/bin, /usr/share/man und was sonst noch so anfällt und schreibe mir die Links in eine Datei, so dass ich alles schnell löschen oder auf neue Versionen umbiegen kann.

Nicht dass Ihr denkt, ich sei übergelaufen; mein BSD läuft aber so rund, dass ich genug Zeit für solche Spielereien habe und ich habe nicht wenig dadurch gelernt. ;)

Also, wenn Ihr nützliche Tips zum Thema Abhängigkeiten, oder sogar ein paar Tools kennt, teilt Euer Wissen.

Später kommt das dann wohl auch FreeBSD zugute, wenn ich meine ersten Ports mache!

Warum ich das nicht in ein Linux-Forum poste? Weil ich weiß, dass ich hier die besten Antworten bekomme! Is ja auch nur Geplauder... ;)
 
Ganz einfach:

Auf der website des Projekts sind normalerweise irgendwo in der Dokumentation die Abhängigkeiten aufgezählt.
 
Danke für die schnelle Antwort!

Eigentlich hast Du ja Recht, aber leider kann man sich nicht darauf verlassen.

Mal ein einfaches Beispiel:

cadaver, das ist ein WebDAV-Client. Analog zu lftp zu nutzen, bloß anderes Protokoll.

Auf der Website sind keine Abhängigkeiten zu finden, und

# tar xvf cadaver-0.22.3.tar.gz &&
> cd cadaver-0.22.3 &&
> grep -i dependencies * | grep -i openssl
#

gähnende Leere, auch wenn man die Suche auf dep ausweitet (EDIT oder grep -i -5 dep | ... ).

Natürlich kann man sich denken, dass man für https openssl braucht, aber erwähnt wird das Nirgendwo.

Das ist ein ganz kleines Progrämmchen, bei dem das alles klar auf der Hand liegt, auch ohne Doku; ist ja auch nur ne optionale Abhängigkeit, aber wenn einem sowas bei einer größeren Geschichte in die Quere kommt kann das richtig in Arbeit ausarten...

Deshalb die Frage, wie Ihr mit sowas (Erfahrungswerte) umgeht, um unnötige Arbeit zu vermeiden.

EDIT: Im Makefile hätte ich das natürlich bemerkt, aber stell Dir das mal bei riesigen Projekten vor, falls die nicht ordentlich dokumentiert sind. Wir sind ja nicht bei BSD... Da muss es doch nen Königsweg geben? :rolleyes:
 
Last edited:
Blöderweise gibt es keine standardisierte Form Abhängigkeiten zu dokumentieren, aber auch unter LFS sollte es möglich sein ein Paketsystem nachzurüsten.
 
Ja, es gibt verschiedene Paketmanager, die speziell für LFS entwickelt wurden, die lösen aber in der Regel keine Abhängigkeiten auf, sondern sorgen dafür, dass man installierte Programme wieder problemlos entfernen kann, respektive weiß was wo installiert wurde.

(Ein anderer interessanter Ansatz wäre z.B. jedem installierten Programm seinen eigenen User zu geben :ugly: )

Das klappt aber nach meinem System (hoffentlich) auch. Ich hab's sogar teilweise automatisiert (naja, im Ansatz...:rolleyes: ). Das ist zwar das Rad neu erfinden, aber es geht ja in erster Linie den Lerneffekt.

Im Prinzip ist es auch möglich apt-get, rpm oder sogar Portage (so heißt das Gentoo Port-Dingsbums doch?) draufzusetzen, aber das wäre im Moment nicht der Sinn der Sache.

Es geht ja gerade ums Selbermachen, aber vielleicht _ist_ es ja einfach wirklich so stressig und es gibt keine halbwegs bequeme Lösung...

Ich hab aber auch fast noch keine Erfahrung; vielleicht sind bei den größeren Projekten ja Dateien mit den entsprechenden Abhängigkeiten dabei? Werd ich ja dann rausfinden... :)

(Zum Glück gibts für den Anfang BLFS, damit bekommt man dann schon ein 'gebräuchlicheres' System, die geben die Abhängigkeiten mit an und liefern Patches frei Haus :D)
 
Ich habe mir (für FreeBSD, mit chroot auch auf Linux machbar) die Jailmethode ausgedacht:
1. Man nehme ein sauberes Jail, in dem sich nur die Base befindet
2. Man versuche sein Programm zu kompilieren
3. Da nichts außer der Base installiert ist, wird er sich nun über jede fehlende Abhängigkiet, also kurz alle, aufregen.
4. Mit Google sollten sich zugehörige Programme (meist spuckt er nur fehlende Libs oder Includes aus) identifizieren lassen.
 
Hallo Yamagi!

Das klingt nach einer sicheren Methode! Ist zwar auch ein Bisschen Arbeit, aber ich habe vom Basissystem und von der chroot-Umgebung Achive angelegt. Die haben entpackt 300MB (Basissystem) das ist also wie nix installiert und da kann man ja auch nix kaputtmachen.

Die Methode ist zum portieren auf jeden Fall gut geeignet. Trotzdem wäre mir das ohne BLFS wohl zu stressig... Ich müsste das dann ja für jedes einzelne Programm machen. Obwohl, man muss ja nicht den Teufel an die Wand malen, es wird ja auch gut dokumentierte geben.

Vielen Dank für den Tip, das kann ich bestimmt noch gut gebrauchen!


Zum Thema Paketmanager:

Bitte nicht Lachen, es ist mehr eine Krücke als ein "Manager" aber er nimmt mir schon einige Arbeit ab (beim deinstallieren, draufhauen ist ja kein Problem). Ich hab das halt nicht gelernt und spiele nur rum, aber ich hab keine Zeile geklaut, alles meins ;).
Der ist noch nicht richtig fertig und auch nicht sicher, aber ich hab ja Zeit. Leider ist mir der letzte Speicherstand flöten gegangen, aber das Prinzip ist wohl klar:
Code:
###############################################
### SPAME, the Smallest Package Manager Ever  # 
### Daniel Leidisch                           # 
### Version 0.0.1a                      BSDL  #
###############################################
###
###
### Usage:
### ======
### 
### 1. $ ./configure --prefix=/usr[/local]
### 2. $ make
### 3. # make prefix=PKGDIR/PACKAGE
### or # make DESTDIR=PKGDIR/PACKAGE 
### 4. # cd PKGDIR/PACKET && spame -c 
###
### to install your files into a PKGDIR/PACKAGE
### tree and execute spame within it. The files will be 
### symlinked to /usr[/local] and a PACKET.links file 
### will be created, which contains the names and absolute 
### paths to those links.
###
### If a link would end up in a missing dir, ln -s fails. You
### can decide yourself as to how to handle this.
### Either you create the links and directories listed in
### PACKAGE.failed manually, or you use the -d option.
### You should run -u before -d, because else you would 
### mess up your PACKET.links and PACKET.failed files.
### PACKET.failed usually consists of links to nonexistant
### dirs only, but you should (and) can double check.
###
### Log your actions with tee, just to be sure!
###
### If you dont export a PKGDIR variable, /usr/local/pkg
### is set as default 
### 
### To remove the created links, just enter the package
### directory and run spame -u
###
### spame -c creates the symlinks
### spame -u deletes created symlinks
### spame -r removes directories created with -d
### spame -R removes directories created with -d w/parents!!!
### spame -l gives a list of symlinks
### spame -f shows the list of failed symlinks
### spame -d creates missing directories, so you can
###	     run spame -c again to install PACKAGES.failed
### spame -v shows current version
### spame -h help
###
### NOTE: If the mentioned options are not supported,
###       you'll have to check the Makefile. For most
###       newer tarballs it will work.
###
 
#!/bin/sh


PACKAGE=$(basename $(pwd))
PKGDIR=${PKGDIR:-/usr/local/pkg}
HELPTEXT="Hilfe ist unterwegs..."


## check, if spame is run within a valid pkg directory

pwd | grep -e "^${PKGDIR}/[[:alnum:]_][-[:alnum:]_\.]*$" >/dev/null 2>&1 ||
{	
	# no, so print an error message and leave 
	
	echo "You must cd to a proper pkg-directory, like"
	echo "${PKGDIR}/PACKAGE" 
	echo "in order to run spame!"
	echo	
	exit 1 
}


getopts curfvldh OPTION	# only the first Option counts!!!

case $OPTION in
	u) echo -n "Really delete ${PACKAGE} links? (y/n) "
 	   read		
	   if [ "$REPLY" = 'y' ]; then 
		xargs rm -v < "${PACKAGE}.links"
		rm "${PACKAGE}.links"
	   else
		echo "Leaving..."
	   fi
	   exit 0
	;;

	v) echo "SPAME 0.0.1a" 
	   echo
	   exit 0;;

	l) echo "${PACKAGE}.link list:"; echo
	   cat "${PACKAGE}.links" 
	   exit 0;;

	h) echo "${HELPTEXT}"
	   exit 0;;

	d) echo "Creating directories of failed links:"
	   exec 4<&0
	   exec < "${PACKAGE}.failed"
	   while read LINE; do
		mkdir -pv "$(dirname ${LINE})"
	   done
	   exec 0<&4 4<&-
	   exit 0;;

	f) echo "Failed symlinks:"
	   cat "${PACKAGE}.failed"
	   exit 0;;
	
	r) echo "Remove directories created by -d:"
	   exec 4<&0
	   exec < "${PACKAGE}.failed"
	   while read LINE; do
		rmdir -v "$(dirname ${LINE})"
	   done
	   exec 0<&4 4<&-
	   rm "${PACKAGE}.failed"
	   exit 0;;

	R) echo "Remove directories created by -d, including all empty parents."
	   echo "This is the only option which could leave your system changed."
	   echo -n "(You should have checked ${PACKAGE}.failed) Are you sure? (y/n) "
	   read
	   if [ $REPLY = 'y' ]; then
		exec 4<&0
		exec < "${PACKAGE}.failed"
		while read LINE; do
			rmdir -vp "$(dirname ${LINE})"
		done
		exec 0<&4 4<&-
	   else
		echo "Leaving..."
	   fi
	   exit 0;;
		
	c) ;;

	*) echo "usage: spame [-c|-u|-r|-R|-l|-f|-v|-h]"
	   echo
	   exit 2;;
esac



## create the symlinks and store absolute paths in
## PACKAGE.links

FROMDIR=$(pwd)
TREE=$(find . -mindepth 2 | sed 's@\.@@' 2>/dev/null | xargs)

for FILE in $TREE; do
	# we don't want directories to be symlinked, since that
	# is handeled through -d, to gain more control 
	if [ -f ./$FILE ]; then
		# create links
		ln -sv "${FROMDIR}${FILE}" "${FILE}" && 

		# create PACKAGE.links
		echo "${FILE}" >> "${PACKAGE}.links" ||
		
		# make a list of files that failed, for example those
		# that tried to link in a non-existent directory
		# you might install these manually, or run spame -u,
		# create the dirs (spame -d) and run spame -c again. 
		# when uninstalling completely, the PACKAGE.failed file
		# still shows the directory paths (until spname -r).
		echo "${FILE}" >> "${PACKAGE}.failed"
	fi
done             

exit 0

Naja, mir hilft er, aber ich würde ihn wohl keinem empfehlen :p

EDIT: Hab die richtige Version doch noch gefunden. Nicht, dass sie viel besser wäre, aber sie funktioniert einigermaßen... ;)

Ansonsten gilt: Its not a bug, its a feature! :cool:

FINAL EDIT:
Heute hat mich der Wahnsinn gepackt. Ich hab den Post jetzt bestimmt schon 10 mal editiert, aber es hat mir keine Ruhe gelassen. Das Teil funktioniert jetzt ganz gut für meine Zwecke. Vielleicht kann ja auch sonst jemand was damit anfangen... Es ist kein vollautomatisches Teil und so ausgelegt, dass man immer nur einen Schritt macht; schließlich gehts um den Durchblick und Ordnung in /usr. Wenn jemand es nutzen will: Auf eigene Gefahr! ;)
 
Last edited:
Back
Top