CD-Satz + Packages erzeugen

[coolgabriel]

Hallo

wie kann man einen cdsatz erzeugen also mit den packages, so wie der cdsart von netbsd. also so cd1-7 für die packages und zwar so das man die packages mit dem sysinstall installationsmanager von cdrom installiren kann, gibt es irgetwo im netz soetwas???

oder wie mann man sich soetwas selbst erzeugen???

 

[agnus]

Script

Hallo

wie kann man einen cdsatz erzeugen also mit den packages, so wie der cdsart von netbsd. also so cd1-7 für die packages und zwar so das man die packages mit dem sysinstall installationsmanager von cdrom installiren kann, gibt es irgetwo im netz soetwas???

oder wie mann man sich soetwas selbst erzeugen???

Es gibt ein Script zum Download auf:
http://www.cul.de/data/managepkg-1.1.gz
Es sucht den Ports-Tree komplett durch und generiert *.tgz.
Achtung : das Script braucht zu diesem Zweck den Paramater "make-package" oder so ähnlich. Ohne Parameter fängt es angeblich an, Deinen gesamten Portstree downzuloaden und zu installieren. Wäre ziemlich aufwendig.
Also aufpassen.
Nach dem abarbeiten habe ich in /usr/ports/packages einen kompletten *.tgz Baum gefunden. Wie der jetzt weiterverarbeitet werden kann (auf einer anderen Maschine zum Beispiel, weiß ich allerdings noch nicht, da ich selber noch ein Rookie bin).

 

[0815Chaot]

Habe mir das Skript interessehalber angesehen. So heißt es da z.B.:

  echo "Help on `basename ${0} version 1.1:`"
  echo "Parameters:"
  echo "   (without params) : Runs \"make\" in all directories."
  echo "   command          : runs \"make command\" in all directories."
  echo "   command dir      : run \"make command\ in the sub tree \"dir\"."
  echo "   -h[elp]|-HELP    : Shows this help screen."
  echo "   package-recursive: Packages all already build ports."

Ohne Angabe eines Parameters wird also einfach nur ein "make" für alle Ports ausgeführt. Wenn du Packages bauen willst, mußt du als Argument "packages" angeben. Mit "package-recursive" wird offensichtlich nur aus den Ports, die bereits gebaut wurden, ein Package generiert.

Zwei Sachen fallen mir spontan auf. Zunächst heißt es auch in dem Skript:

  echo "Warning: The run of the script may last days (but you may stop it any time)."

Ist ja auch klar - es müssen immerhin alle Distfiles runtergeladen werden und das Kompilieren dauert auch seine Zeit (ich denke mal an Ports wie KDE, GNOME, OpenOffice, XFree usw.). Daher meine Frage an agnus, welchen Boliden er da verwendet hat und wie viele Wochen er warten mußte

Zweitens habe ich meine Zweifel an dem Erfolg von "package". Zum Bauen eines Packages ist es unter FreeBSD nämlich zwingend notwendig, zuerst ein "install" auszuführen. Wenn der Port schon installiert ist, wird ein "install" aber fehlschlagen. Ein "package" läuft dann natürlich auch nicht. Da das Skript Fehler in einem make-Lauf ignoriert und mit dem nächsten weitermacht, wird der Port einfach links liegen gelassen.

Knuddelig wird es dann, wenn eine Dependency nicht aufgelöst werden kann, weil sie schon installiert ist oder weil man das Distfile manuell runterladen muß (wegen der Lizenz). IMO ziemlich schwierig, das hinterher nachzuvollziehen, was da jetzt genau gebaut wurde.

Drittens: Bedingt durch die Tatsache, daß man vor einem "package" ein "install" braucht, hat man den Port dann auf dem System installiert. Im Zweifel sind das alle Ports. Wobei sich einige auch in Quere kommen dürften.

Ich würde also empfehlen, dieses Skript auf einer "nackten" Installation aufzurufen, auf der nur Base ohne einen einzigen Port installiert ist. Dann holt man sich einen aktuellen Ports-Tree und läßt das Skript rattern.

BTW, bevor man tagelang kompiliert, kann man sich die Packages auch auf ftp://ftp.de.FreeBSD.org/pub/FreeBSD/ports/packages runterladen. Wenn man dort mal in das Verzeichnis "All" reinguckt, bekommt man auch ein Gefühl dafür, wieviel Speicherplatz sämtliche Packages belegen - das sind 8,6 GB! Und da fehlen glaube ich noch Sachen wie Java, weil das mit der Lizenz sonst nicht hinhaut.

Zur Frage, wie man diese Packages dann benutzt: Zuerst muß man die auf einem Datenträger ablegen, auf den der Rechner, auf welchem man die Packages installieren möchte, zugreifen kann. Idealerweise vielleicht ein NFS-Share, ob das Zeug auf eine DVD paßt, weil ich nicht. Das auf mehrere Wechseldatenträger zu verteilen ist wohl schwierig, weil man dann die Dependecies für alle Pakete auf dem Datenträger auflösen können muß.

Nehmen wir also mal an, man hätte das Verzeichnis /usr/ports/packages auf einem Datenträger, der nach /mnt eingehängt wäre:

cd /mnt/All
export PKG_PATH=`pwd`
pkg_add x3270-*

Damit würde man das Package für das 3270-Terminal installieren. Abhängigkeiten zu anderen Packages würden automatisch aufgelöst.

So, jetzt habe ich viel über das Skript gelabbert. Dabei dürfte coolgabriel sich wohl denken: "Was ein Lall, sowas habe ich doch gar nicht gesucht!" Stimmt Du wolltest eigentlich wissen, wie man Packages auf mehrere CDs verteilt, so daß man sie mit sysinstall reinbügeln kann. Ist IMO schwierig, weil man eben die abhängigen Pakete immer auf der selben CD haben muß. Wie man das hinbekommt, weiß ich nicht. Komplizierte Sache. Du kannst versuchen, mit /usr/ports/INDEX zu arbeiten, da stehen für jeden Port die R-Deps drin. Außerdem mußt du dann auf jeder CD eine ebensolche INDEX haben, in der alle Packages der CD aufgeführt sind, sonst erkennt sysinstall das nicht.

 

[agnus]

Daher meine Frage an agnus, welchen Boliden er da verwendet hat und wie viele Wochen er warten mußte

Mein package-recursive hat ca. 6 Stunden gedauert.
Laut Anleitung im FreeBSD-Buch generiert das Script alle Ports, in deren Verzeichnis ein WORK Directory mir Daten ist. Soll heißen, Diejenigen, die mit make install bereits installiert wurden.
Da ich nirgendwo "clean" angegeben habe, waren offensichtlich alle benötigten Dateien noch im Port-Tree vorhanden.
Danch löscht das Script diese Work-Dateien.
Lästig war nur, daß das Script vor jedem parametriebaren Port stehenbleibt und die Auswahlmaske der Komponenten anzeigt. Diese muß man bestätigen - erst dann gehts weiter. Wenn man nicht stundenlang gebannt vor dem Rechner sitzt und auf diese Eingabeaufforderung wartet, ist die Zeit daher nur schwer zu messen.

Zum Boliden: verwende z.Zt. auf meinem "Erstversuch-BSD-Server" einen P4-2,8 mit 1GB Ram und 360 GB HD(1x 120 IDE als Boot, 2x 120 SATA als Datenspeicher).
Das make install für kde3.2.3 hat mehrere Stunden benötigt. Allerdings kann ich nicht sagen, wie lange er jeweils auf meine Eingaben zur Auswahl der optionellen Komponenten wartete.

 

[0815Chaot]

Mein package-recursive hat ca. 6 Stunden gedauert.
Laut Anleitung im FreeBSD-Buch generiert das Script alle Ports, in deren Verzeichnis ein WORK Directory mir Daten ist.

Ja, so habe ich das beim Überfliegen des Skripts auch verstanden. IMO ist package-recursive auch die einzig sinnvolle Anwendung bei diesem Skript. Da kann man zuerst ganz "normal" seine Ports mit make bauen und anschließend einfach von diesen ein Package generieren lassen. Packages für alle Ports zu bauen halte ich für unsinnig, das hatte aber wohl ohnehin niemand vor.

Lästig war nur, daß das Script vor jedem parametriebaren Port stehenbleibt und die Auswahlmaske der Komponenten anzeigt.

Dem sollte man abhelfen können, wenn man BATCH=YES (oder so ähnlich) setzt.

Zum Boliden: verwende z.Zt. auf meinem "Erstversuch-BSD-Server" einen P4-2,8 mit 1GB Ram und 360 GB HD(1x 120 IDE als Boot, 2x 120 SATA als Datenspeicher).

Ok, das ist schon ein "nicht ganz langsames" Maschinchen Wobei du ja nicht alle Ports gebaut hast (was ich auch nicht für sinnvoll hielt). Mich würde mal wirklich interessieren, ob schon mal jemand alle Ports gebaut hat, ob das einigermaßen funktioniert und wie lange das braucht. Aber ich glaube, sowas macht nicht wirklich jemand

 

[agnus]

Batch=yes

Das wäre eine interessante Option.
Besonders wenn einmal wer wirklich alle Ports bauen will. Die Hauptschwierigkeit ist ja, daß man quasi daneben sitzen muss, weil irgendein Port wieder wissen will, ob man die Unterstützung für "A" "B" oder "C" will und dann nicht weitermacht, bis man bestätigt hat.

By the Way: Bin gaaanz stolz, obwohl BSD-Neuling ist es mir auf Anhieb gelungen, einen BOOTBAREN Kernel zu generieren, der meine gesamte Hardware (abgesehen von einer Audigy, die wird auch mit emu10...nicht erkannt) serviciert und zudem statt 5M nur 1.2M groß ist.
Das ist bei allen mir bekannten Linux-Derivaten schwieriger.
Dafür war das nachträgliche Einbinden der Festplatten eine echte Challenge.

 

[0815Chaot]

Das wäre eine interessante Option.
Besonders wenn einmal wer wirklich alle Ports bauen will. Die Hauptschwierigkeit ist ja, daß man quasi daneben sitzen muss, weil irgendein Port wieder wissen will, ob man die Unterstützung für "A" "B" oder "C" will und dann nicht weitermacht, bis man bestätigt hat.

Ich weiß allerdings nicht, was make macht, wenn man BATCH=YES setzt. Wählt das dann alle möglichen Optionen aus oder gar keine oder nur ein paar? Ich mein, wenn man gefragt wird, kann man es sich ja aussuchen, aber was macht make, wenn man ihm sagt, daß es nicht fragen möchte?

By the Way: Bin gaaanz stolz, obwohl BSD-Neuling ist es mir auf Anhieb gelungen, einen BOOTBAREN Kernel zu generieren, der meine gesamte Hardware (abgesehen von einer Audigy, die wird auch mit emu10...nicht erkannt) serviciert und zudem statt 5M nur 1.2M groß ist.
Das ist bei allen mir bekannten Linux-Derivaten schwieriger.

Erstmal herzlichen Glückwunsch Wobei man wirklich zugeben muß, daß das Kernel-Übersetzen bei Linux tatsächlich mühsamer ist. Wenn man einmal das Prinzip der FreeBSD-Kernel-Konfigdatei verstanden hat, ist es kein Problem mehr.

BTW, mein Kernel ist 2,3 MB groß. Hauptsächlich dadurch, daß ich SCSI drin habe, um beispielsweise USB-Sticks mounten zu können. Da muß man halt immer abwägen, was man machen will. Ich habe lieber ein bißchen mehr im Kernel, als daß ich wegen jedem Furz, an den ich damals nicht gedacht habe, noch mal den Compiler anwerfen muß

Die Audigy sollte aber auch noch zur Mitarbeit zu bewegen sein. Meist kommt man mit dem mitgelieferten emu10k-Modul nicht weit. Aber such mal hier im Board, da gibt es einige Hinweise auf verschiedene Kernel-Module, mit denen man zum Erfolg kommen kann.

Dafür war das nachträgliche Einbinden der Festplatten eine echte Challenge.

Naja, wenn man das mit sysinstall macht, kann eigentlich nicht viel schief gehen.

 

[agnus]

Naja, wenn man das mit sysinstall macht, kann eigentlich nicht viel schief gehen.

Also so aus der Erinnerung (Bin grad im Büro, da gibt's kein vernünftiges BS)
1. sysinstall
2. configure
3. fdisk (ad2 ausgewählt - ad1 ist meine Bootplatte)
4. mit "A" gesamten Bereich für BSD gewählt
5. Mit "Q" ausgestiegen
6. keinen BMGR installieren lassen
7. sysinstall komplett verlassen
8. sysinstall / configure /label (ad2)
9. C für Create am Anfang kam eine Meldung so wie: das geht nur für master partitions oder ähnlich
Nach eineigen Versuchen konnte ich dann doch die größe angeben.
dann fragt eín Dialog nach dem Mountpoint und wenn ich den angebe (einen existierenden pfad (/sata) gibts einen....
...
core dumped
Funktioniert hat es erst. als ich entgegen aller warnungen und Dialogboxen
beim Punkt 5 statt "Q" mit "W" aus dem Fdisk ausgestiegen bin.

Wegen der Audigy werde ich halt noch einmal den google und die Suche hier im Forum bemühen. Vielleicht habe ich jetzt mehr Glück als am Wochenende.