Es geht ja darum, die Pakete zu erstellen, und nicht, sie zu installieren. (Wobei ich bis jetzt auch nur checkinstall genutzt habe.) Allerdings frage ich mich, wo die Unterschiede zu makepkg sind, mal abgesehen von einem vorgefertigtem Script.
Sehr guter, informativer Artikel! Checkinstall ist perfekt fuer den "Hausgebrauch", aber wenn man die volle Kontrolle will und die Pakete vielleicht sogar veroeffentlicht, ist protopkg sicher die bessere Wahl.
Und was meinst du wohl was man mit Checkinstall wohl machen kann?
Jo, genau richtig.
Pakete erstellen. (nicht nur installieren, da würd auch make install reichen. Die Pakete kann man übrigens auch weiterreichen, archivieren oder sonstwas mit machen funktioniert alles.)
Nun gut, ich habe mir jetzt den Artikel durchgelesen, erstmal danke an Sebastian Kwiatkowski.
Also die einzigen Vorteile die ich auf den ersten Blick bei protopkg sehe, sind. hm..(nachdenk...)
Also ne automatische nicht interaktive Installation soll checkinstall inzwischen auch per Paramterübergabe können (habs noch nicht getestet).
Paket Beschreibungsangaben ok, da das ne Textdatei ist, die man jederzeit wiederverwenden und vor allem editieren kann könnte das ein Vorteil sein. Und bei mehrmaligem compilieren muß man den Paketbeschreibungs Text nicht jedesmal neu schreiben, inwieweit das bei Checkinstall möglich ist, weiß ich nicht aber per script und Paramterübergabe liese sich das auch sicher auch mit Checkinstall voll automatisieren inklusive Beschreibungstext und co.
Also um Pakete zu verbreiten scheint es ganz brauchbar zu sein.
Aber ein wirklicher Vorteil gegenüber checkinstall will mir nicht wirklich einfallen.
Von der Bedienung her ist es wesentlich umständlicher als Checkinstall, da ist Checkinstall eindeutiger Sieger.
Und bisher kam ich mit checkinstall immer ganz gut zurecht.
Ich seh es mal als Alternative falls ich es mal brauchen sollte.
@Catonga Da faellt mir spontan ein Beispiel ein, bei dem Checkinstall Schwaechen hat: Installiere mit Checkinstall ein Programm, dessen Installscript eine Konfigurationsdatei modifiziert (z.B. den Nvidia Kerneltreiber, rp-pppoe usw.). Entferne das Paket dann mit removepkg und suche Deine Konfigurationsdatei!
Ich hab meine Packete bisher immer manuell mit makepkg erstellt, da mir checkinstall in einigen Punkten nicht gefallen hat (zum Beispiel immer die Endung -pak.tgz, das description file wird über doinst.sh aufgerufen...). Es ist zwar einfacher als auch dieses Protopkg, allerdings eignet sich Protopkg sicher zum managen von Packeten, die häufig durch eine neue Version ausgetauscht werden. Da Cantrell den Sparc-Port übernommen hatte, wird das wohl aus der Zeit stammen.
Anstatt die Gelegenheit zu nutzen, sich mal Gedanken um die Zukunft der Domain zu machen, hat sich linux.de offenbar entschlossen, so weiterzumachen wie bisher. Die "Erklärung" für den Breakin ist gradezu MS-like ("der Provider ist schuld"), und die ganze Sache wird als 'Scherz' abgetan. Schade drum.
"
Slackware Pakete erstellen ein Problem???
Also normalerweise verwende ich dazu Checkinstall, damit gehts wie geschmiert.
Aber nun gut, ich werd mal den Artikel durchlesen.
Allerdings frage ich mich, wo die Unterschiede zu makepkg sind, mal abgesehen von einem vorgefertigtem Script.
Marc
Checkinstall ist perfekt fuer den "Hausgebrauch", aber wenn man die volle Kontrolle will und die Pakete vielleicht sogar veroeffentlicht, ist protopkg sicher die bessere Wahl.
Jo, genau richtig.
Pakete erstellen. (nicht nur installieren, da würd auch make install reichen. Die Pakete kann man übrigens auch weiterreichen, archivieren oder sonstwas mit machen funktioniert alles.)
Nun gut, ich habe mir jetzt den Artikel durchgelesen, erstmal danke an Sebastian Kwiatkowski.
Also die einzigen Vorteile die ich auf den ersten Blick bei protopkg sehe, sind. hm..(nachdenk...)
Also ne automatische nicht interaktive Installation soll checkinstall inzwischen auch per Paramterübergabe können (habs noch nicht getestet).
Paket Beschreibungsangaben ok,
da das ne Textdatei ist, die man jederzeit wiederverwenden und vor allem editieren kann
könnte das ein Vorteil sein.
Und bei mehrmaligem compilieren muß man den Paketbeschreibungs Text nicht jedesmal neu schreiben, inwieweit das bei Checkinstall möglich ist, weiß ich nicht aber per script und Paramterübergabe liese sich das auch sicher auch mit Checkinstall voll automatisieren inklusive Beschreibungstext und co.
Also um Pakete zu verbreiten scheint es ganz brauchbar zu sein.
Aber ein wirklicher Vorteil gegenüber checkinstall will mir nicht wirklich einfallen.
Von der Bedienung her ist es wesentlich umständlicher als Checkinstall, da ist
Checkinstall eindeutiger Sieger.
Und bisher kam ich mit checkinstall immer ganz gut zurecht.
Ich seh es mal als Alternative falls ich es mal brauchen sollte.
Da faellt mir spontan ein Beispiel ein, bei dem Checkinstall Schwaechen hat: Installiere mit Checkinstall ein Programm, dessen Installscript eine Konfigurationsdatei modifiziert (z.B. den Nvidia Kerneltreiber, rp-pppoe usw.). Entferne das Paket dann mit removepkg und suche Deine Konfigurationsdatei!
Anonsten: Danke für den Artikel.
Die "Erklärung" für den Breakin ist gradezu MS-like ("der Provider ist schuld"), und die ganze Sache wird als 'Scherz' abgetan.
Schade drum.