Wie Programme unter Linux installieren

[Harry Stahl]

Bislang habe ich für die Installation meiner mit Lazarus/Freepascal erzeugten Linuxprogramme immer eine Beschreibung zur Installation mit Hilfe des Archivmanagers auf meiner Homepage (siehe z.B. hier: http://www.pc-adress.de/Download-PCAdress-Linux.htm).

Das funktioniert zwar, dürfte aber mit Sicherheit nicht der "korrekte" Weg sein, die Programme unter Linux zu installieren. Ich denke die ausführbare Datei sollte wohl in /usr/bin rein?

Hat jemand hier Erfahrungen, gibt es evtl. irgendwelche Installationsprogramme, die man hier verwenden könnte?

[creed steiger]

mit deb und RPM solltest du 90% abdecken

http://wiki.freepascal.org/Deploying_Your_Application

es gibt auch etliche Tutorials dazu, du findest bestimmt was passendes

http://www.linuxforen.de/forums/show...rpm-aus-binary

[cookie22]

Kommt halt drauf an welche Distro deine User benutzen und ob du auch den Code zum selbst compilieren rausrückst. Wenn du allerdings keinen festen Kundenstamm hast, wirst du mit Closed Source bei Linuxern keinen Blumentopf gewinnen.

Deb, RMP und eventuell für alle anderen ein Tarball.

Du kannst das ganze natürlich auch in ein beliebiges Archivformat packen und per Bash Script installieren.

[Harry Stahl]

Danke erst mal für die Antworten.

Auf dieses commandozeilen-zeugs und auf script-dateien stehen ich allerdings nicht so sehr. Eigentlich müsste es ja auch gehen (so wie ich das unter Windows mache) alle Dateien in eine ausführbare Setup-Datei packen und die starten dann die Installation durchführen.

Oder spricht da etwas dagegen?

[creed steiger]

Im Prinzip nicht aaaaaaber .....

eigentlich ist die Paketverwaltung der zentrale Punkt für die Softwareverwaltung, sprich Installation, Deinstallation, Verwaltung von Abhängigkeiten und Updates.

Mit einem Script beraubst du dich dieser Vorteile.

[implementation]

Einige Programme machen das tatsächlich so. Aber Freunde findest du damit nicht. Als GNU/Linux- oder BSD-User ist man es einfach gewohnt, einen Paketmanager zu benutzen. Und im Idealfall läge dein Programm sogar bei einigen Distributionen in den Repos, dann startet man einfach den Paketmanager, sucht dort dein Paket und klickt auf Installieren, und darüber gehen dann auch Updates.
Klar kannst du es auch einzeln als Paket bündeln und auf deine Website stellen. Ist immer noch unangenehm, aber wird *viel* eher akzeptiert als so ein Setupprogramm.

Und auf jeden Fall Pluspunkte gibts für zusätzlich einen Tarball (ergo .tar.gz, .tar.bz2 oder .tar.xz), in dem die Quelldateien liegen, und im Idealfall muss man zum Kompilieren nur hineinwechseln und "./configure && make" eingeben und schon wirds kompiliert, denn daran ist man gewöhnt und da muss man sich keine Gedanken mehr machen, wie das denn jetzt kompiliert wird. Wenn du dir so eine Makefile nicht zutraust, ist das auch kein Halsbruch, hauptsache du lieferst die Sourcen irgendwie aus. Denn sonst steht derjenige blöd da, ders auf einmal auf seinem MIPS-Router laufen lassen will, oder auf seinem SPARC-Server - das sind Szenarien, um die man sich bei Windows-Entwicklung gar keine Gedanken macht, die aber bei GNU/Linux auf einmal relevant werden und ein Mitgrund dafür sind, dass proprietäre (Closed Source) Software wenig Anklang findet. Neben der Tatsache, dass freie Software dort so verbreitet ist, dass proprietäre wirklich ins Auge sticht und man sich als potenzieller Nutzer Gedanken macht: "Was will der da vor mir verbergen?".

Also ich fasse zusammen: Closed Source bringt dort unheimlichen Marktnachteil. Und Setups schrecken eher ab, da vergleichsweise unbequem und sehr ungewohnt. Wenn du viele Nutzer ansprechen willst, halt dich an die dort üblichen Konventionen.

P.S.: Das mit den Konventionen solltest du auch nicht nur auf den Installer beziehen, es gibt noch einige andere Dinge, die manchmal ein bisschen anders üblich sind als unter Windows. Wenn dein Programm z.B. Kommandozeilenparameter annehmen kann, solltest du nicht die Windows-Syntax ("/s", "/help", ...) nehmen, sondern die traditionelle Unix- ("-s", "-abc" = "-a -b -c") bzw. GNU-Syntax ("--lange-optionen", "--help"). Und --help sollte man sowieso immer behandeln, auch wenn du sonst keine Parameter akzeptierst, denn das wird man immer aufrufen, wenn man auf der Konsole grad nicht mehr weiß, was der Befehl macht. Alternativ guckt man in die Manpage, aber wer kein --help behandelt, liefert üblicherweise auch keine Manpage aus. Wenn du das nicht alles direkt bieten kannst, ist das auch kein Beinbruch, aber i.d.R. will man ja nicht negativ auffallen

P.P.S.: Und noch was: Wenn du dich tatsächlich doch noch für einen Setup entscheidest, dann pack die Binary bloß nicht direkt in /usr/bin! Das ist für den Paketmanager gedacht! Alle anderen Installationen, wie auch immer sie durchgeführt wurden, nach /usr/local/bin oder /opt, sonst bringst du den User völlig durcheinander.

[mensch72]

@implementation

sehr schön geschrieben

Jeder so wie er mag, ich bin Happy mit unseren Windows Benutzern, die auf irgendwas mit "Install" oder "Setup" klicken wollen und die außer der anschließend erwarteten Funktion überhaupt nicht interessiert was da wie auf ihrem Computer abläuft.

Mac USER klickten bisher halt auf ein "DMG", jetzt wollen/sollen/müssen die sich alles im AppStore holen. Bis auf die Herstellerkontrolle aller meiner theoretisch immer möglichen und früher wenn's nötig war auch mal mehreren Updates pro Tag für Kunden (ähh Tester), hab ich da wenig Problem damit.
Im Mobil Bereich ist das Verfahren ja auch so.


Ich sehe CloseSource Anwendungen als Futter für die breite Masse die sich nicht für Computer interessieren. Wenn bei denen was per "OneClick" geht sind die glücklich und zahlen dafür Geld.
Wenns nicht geht, suchen&nehmen sie was anderes. Selber in den Code schauen ist da kein Thema.
Wer anders denkt interessiert mich als Kunde nicht.

Auch der Kaufpreis ist meist kein Thema, solange der Kunde schnell genug mehr durch den Nutzen verdient wie die Sache kostet. Und "Nutzen" ist relativ. Manchen ist etwas Komfort oder Sicherheit sehr viel Geld wert.

Aus Prinzip werde ich Linux "XYZ" mir selbst und für die Masse erst ernsthaft anschauen wenn es zu 95% so "vereinheitlicht" wie Windows oder MAC für "OneClickUser-Installationen" nutzbar ist.
Bis dahin nutze und sowenig wie möglich OpenSource... und die für die ich arbeite finden das gut


Zurück zum Thema:
Binary-Installer unter Linux sind eigentlich nicht das Problem, das ist lösbar. Doof waren in den wenigen Fällen wo ich ein paar Sachen machen musste die Probleme, wenn "schlaue Leute" sich immer die neuesten Sachen und Patches in den Kernel einbauen und dann meckern, wenn man selbst das nicht macht oder so testet.

-> für Servertools ohne GUI halte ich BinaryInstaller bei den bekannten großen Distributionen für beherrschbar
-> Wenn jemand aktuell was mit GUI unbedingt mit Linux nutzen will, dem mache ich ein WebInterface
-> aktuelles Delphi+Intraweb+Cgdevtools bieten da auf JQuery-Basis optisch&funktional sehr schöne Möglichkeiten... kosten in Kombi zwar Geld, aber man "erschlägt" mit dem WebGUI Konzept alle Plattformen auf einmal... Vom Win,Mac,Mobile,Linux aber auch SmartTV bis zum RasperryPI!
-> da mich wie erwähnt aktuell die AppStores für schnelle Updates&Erweiterungen nerven, machen wir das bei Bedarf zunächst "schnell" als WebGUI und realisieren ausgewähltes beim nächsten Release eventuell per NativeDialog
-> aber weil die Kunden doch lieber ein Programm oder eine App starten wollen, liefern wir da teilweise nur noch einen "NativeClient" mit einem "verstecktem" embedded WebBrowser ohne sichtbares Adressfeld. Das Miniprogramm ist quasi nur ein hohler dummer Vogel was nur die WebSite des WebServices fest aufruft und eventuell noch das Login native automatisiert realisiert


Viele Wege führen nach Rom...

[Namenloser]

Also mir persönlich käme nichts auf den Rechner, was ich nicht über die Paketverwaltung installieren und deinstallieren kann. Bei einem fremden Installer besteht immer die Gefahr, dass er mir irgendwie das System zerschießt, oder dass sich das Programm hinterher nicht mehr sauber entfernen lässt. Außerdem habe ich keine Lust, wenn 99 % meines Systems sich einheitlich über den Paketmanager verwalten lassen, nur für dein Programm eine Ausnahme zu machen und mich auf die Benutzeroberfläche von deinem Installer/Uninstaller einzustellen. Weiteres Problem: Nicht immer kann man unter Unix eine grafische Oberfläche voraussetzen. Hatte selbst schon mal Probleme mit dem X-Server und war dann froh, dass der Textmodus ausreicht, um das System zu warten. Da hätte ich mit einem grafischen Uninstaller Probleme gehabt. In die gleiche Situation kann man kommen, wenn man per SSH aus der Ferne auf einen Rechner zugreift, was unter Unix nicht unüblich ist.

Ein Installer hat also viele Nachteile und, so wie ich es sehe, eigentlich keine Vorteile. Ich würde an deiner Stelle ein .deb- und ein .rpm-Paket bereitstellen. Für den absoluten DAU kannst du ja, falls nötig, noch einen grafischen Installer dazupacken, der einfach im Hintergrund den jeweiligen Paketmanager des Systems aufruft.

[cookie22]

Was spricht dagegen, das Programm als deb und/oder rpm auszuliefern? In den meisten Fällen(99%) startet ein doppelklick auf die Datei das GUI der Paketverwaltung und der User muss nur noch einmal auf Installieren klicken. Das ist wesentlich angenehmer als eine Windows installation. Ausserdem bleibst du so kompatiebel.

[Dalai]

@implementation & Namenloser: *mich anschließ*.

Zitat von Namenloser:

Da hätte ich mit einem grafischen Uninstaller Probleme gehabt.

Naja, es gibt ja durchaus auch Installer, die ausschließlich im Testmodus laufen (Webmin, IIRC damals auch VMware Workstation 3.x). Aber ich stimme zu: .deb und .rpm und ggf. noch ein .tar.gz (.tgz) und die Sache ist erledigt.

MfG Dalai