Mein Projekt als RPM/DEB Paket packen?

[MmVisual]

Ich denke es sollte so gehen:

- Man nimmt z.B. Inno-Tools, damit kann man alles einstellen.
- Dazu braucht es eine EXE, die den Script interpretiert und alles installiert
- Unter Linux sollte das Setup das installiert dann in die deb oder rpm Datenbank mit eintragen (Bei Uninstall können diese auch eine externe EXE aufrufen, das klappt bei mir auch)
- Unter Windows geht das ja schon
- Dann noch für den Mac

Damit könnte man alles über Inno-Tools parametrieren, gibt es schon.
In Inno-Tools noch 3 Tasten rein mit Build RPM, Build DEB, Build DMG.
Beim Installieren von Inno-Setup werden einfach die entsprechenden Programme für Linux usw. mit installiert, somit kann man alles einfach z.B. zip zusammen packen, darin ist dann das Setup vom OS, die Script-Datei sowie nochmals gezippt die anderen Dateien.

Einzige Änderung von Inno-Tools:
unterschiedliche Pfadangaben zulassen für die entsprechenden Betriebsysteme.

[carli]

Meiner Meinung nach sollte ein Install-Maker (msi, dmg, rpm, deb) zum Standardumfang von Lazarus gehören.

Packages sind kein "installers", und in generellen ist *nix nicht Windows. Wie schneller man sich daran gewohnt, wie besser.

Das ist mir schon klar,

aber im Grunde haben alle Programme gemeinsam, dass sie eine ausführbare Datei und ein paar Zusatzdaten haben.

Jedes OS hat andere Orte, an denen die Dateien verteilt werden müssen. Im Grunde sollte Lazarus mich aber schon dabei unterstützen, mein Programm nicht nur zu entwickeln, sondern auch zu verbreiten.

[marcov]

Meiner Meinung nach sollte ein Install-Maker (msi, dmg, rpm, deb) zum Standardumfang von Lazarus gehören.

Packages sind kein "installers", und in generellen ist *nix nicht Windows. Wie schneller man sich daran gewohnt, wie besser.

Das ist mir schon klar,

aber im Grunde haben alle Programme gemeinsam, dass sie eine ausführbare Datei und ein paar Zusatzdaten haben.

Unix hat eine Tradition um die Programme zu kompilieren auf das System wo sie genutzt werden, und deshalb nicht viel Unterstützung für binäre Installation. Zb was auf Window mit Paramstr(0) gemacht wird, wird auf Unix oft getan durch das Installationsverzeichnis hart in der Binary ein zu backen.

Ja, es gibt Package Systeme wie RPM und deb, aber die sind originell mehr gemeint um Kompilationszeiten zu vermeiden, und nicht um eine Portable Installation (über Versionen oder Distributionen) möglich zu machen.

Jedes OS hat andere Orte, an denen die Dateien verteilt werden müssen. Im Grunde sollte Lazarus mich aber schon dabei unterstützen, mein Programm nicht nur zu entwickeln, sondern auch zu verbreiten.

Das ist das kleinere Problem. Orte usw sind nur sehr grob Linux-weit standardisiert, und nicht eben ganz stabil innerhalb eine Distribution. (also von Fedora 13->14).

Aber das größeres Problem ist das nicht triviale Binaries schon gar nicht Portabel sind. Schon wieder nach Distribution und Version, aber im Praxis ist ab und zu der hand-gepflegte Kompatibilität von eine einzige Linux Distribution in ein einzige Version auch ein Problem. (weniger auf zb RHEL, mehr auf zb Ubuntu, wo Stabilität für ständige schnelle Entwicklung ausgetauscht wird) (typisch Beispiel sind Distributionen die zwei KDE oder GNOME Versionen unterstützen. Alte und neue).

[Targion]

Ich arbeite momentan zusammen mit anderen an Projekten, welche die Softwareinstallation unter Linux vereinheitlichen sollen. Ihr könnt also in Zukunft noch einiges cooles erwarten
Momentan zum Pakete schnüren würde ich den Debian New Maintainer Guide verwenden (für DEB-Pakete) oder die sehr gute Dokumentation von Fedora und openSUSE zu RPM-Specfiles - einfach mal googeln ^^

[carli]

Ich arbeite momentan zusammen mit anderen an Projekten, welche die Softwareinstallation unter Linux vereinheitlichen sollen.

Erhzähl mehr!

Wird das ganze auch AdWare-sicher sein, sodass man keine Angst haben muss, kritischen Paketen Root-Rechte zu geben?

[Targion]

Ist momentan alles noch sehr alpha und die specs sind auch noch nicht fertig. Das Ganze basiert auf meinem Listaller, welchen ich momentan in die distributionsübergreifende Paketmanagement-Abstraktion PackageKit integriere. Unterstützt wird das ganze durch eine neue Freedesktop-Spec für einen Cross-Distro-Appmanager. Grade in diesem Moment läuft in Nürnberg eine Konferenz dazu. (parallel zum Bretzn-Meeting)
Der Listaller-part ist dabei momentan noch umstritten, das Projekt wird aber definitif fertig gestellt und zunächst noch optional sein. Über Adware musst du dir keine Sorgen machen. Über die System-Policy kann man festlegen, dass zum Beispiel generell nur signierte Software mit root-rechten installiert werden darf. Listaller-Pakete enthalten dafür eine GPG-Signatur. Die Pakete basieren auf LZMA2-Komprimierten tarballs, sollte also Adware auftauchen, könnte man die Pakete extrem simpel darauf prüfen. (Große binäre objekte sind momentan in IPK nicht vorgesehen, könnten aber kommen)
Große Probleme bereiten momentan noch einige technische Limits des aktuellen Linux-Ökosystems. Wird aber eventuell geändert.
Ihr könnt übrigens gerne mithelfen beim Projekt Der Kern ist in Pascal geschrieben (obwohl ich eine Zeit lang drauf und dran war, alles auf C++ zu portieren), ansonsten kommen noch Vala, C und C++ sowie Perl und Bash zum Einsatz.

[MmVisual]

@Targion
Könnt Ihr nicht einfach einiges von "Inno-Setup" abschauen?
- Extra-Dialog möglich
- Pascal-Scripte mit allen möglichen Funktionen die man braucht

Ich meine "Inno-Setup" ist so ziemlich das beste was mir je untergekommen ist.

[Targion]

Linux != Windows Es geht nicht darum, eine Funktion von einem anderen System zu kopieren, sondern eine sinnvolle neue Lösung zu entwickeln, die nahtlos in die aktuellen Linux-Umgebungen passt. Was InnoSetup unter Windows kann, muss noch lange nicht für Linux gut sein.
So gehören z.B. unter Linux Konfigurationen in die Anwendung - und sogut wie nur dahin. Damit entfällt im Grunde die Notwendigkeit für Extra-Dialoge. Eventuell wird es aber für den Listaller später ein Debconf-Ähnliches System geben, um Fragen über die Installation zu stellen. (Das hat im Moment aber keine Priorität und wird von vielen auch eh als Unsinn angesehen)
Für Pascal-Scripte würden mich die anderen schlagen - es wird aber die möglichkeit geben, scripte auszuführen, zu verschiedenen Phasen der Installation. Die müssen dann aber in Bash geschrieben sein, da das au eigentlich jedem Linux-System vorhanden ist. Python wird vielleicht auch möglich werden, ebenso wie kompiliertes Zeug. (Obwohl wir da auch noch bedenken haben, da man bei binären Objekten nicht wissen kann, was genau sie tun.)
Also: InnoSettup ist im Grunde eine der Vorlagen (ebenso wie Apples Package-System) die wir im Blick haben, aber Funktionen ohne gründliche besprechung kopieren tun wir nicht ^^

[Socke]

Für Pascal-Scripte würden mich die anderen schlagen - es wird aber die möglichkeit geben, scripte auszuführen, zu verschiedenen Phasen der Installation. Die müssen dann aber in Bash geschrieben sein, da das au eigentlich jedem Linux-System vorhanden ist. Python wird vielleicht auch möglich werden, ebenso wie kompiliertes Zeug. (Obwohl wir da auch noch bedenken haben, da man bei binären Objekten nicht wissen kann, was genau sie tun.)

Schon einmal daran gedacht, dass die Bash nicht auf jedem Linux vorhanden ist? Es gibt schließlich auch noch alternativen wie ksh, csh oder die »alte« Bourne Shell (auch wenn oft gilt /bin/sh -> /bin/bash); Daher bitte ich darum, die verfügbaren Skript-Sprachen auch nur dann zuzulassen, wenn definitiv fest steht, dass sie ausgeführt werden kann (d.h. ein Interpreter installiert ist). Ganz einfach geht das über Abhängigkeiten in allen aktuellen Paketverwaltungen.
Ansonsten bleibt nur die Möglichkeit, die Skripte auf den POSIX-Shell-Standard zu beschränken, der von jedem POSIX-Betriebssystem ausgeführt werden kann.

[Targion]

Daran ist natürlich gedacht, keine Sorge ^^ Das Projekt ist vom gesamten Design her auf Linux-Desktops ausgelegt, ich glaube auch nicht, dass jemand sowas auf dem Server haben will oder gar in eingebetteten Linuxsystemen. Die Vorraussetzungen für Scriptsprachen sind aber auch das geringste Problem. Die größten Probleme liegen in den Shared Libs und anderen Abhängigkeiten einer Anwendung sowie in darin, Software "relocatable" zu machen. (unerlässlich, um sie in andere Ordner zu installieren als eigentlich vorgesehen)
Das "Problem" (ich sehe das eigentlich als großen Vorteil) ist im großen und Ganzen, dass es das eine Linux an sich nicht gibt, sondern verschiedene Software-Kombis mit GNU/Linux als OS-Kern. (aber wofür haben wir die XDG, POSIX und die LSB, wenn nicht für einheitliche Standards?)
(Achja: Das Scriptproblem kann man schon jetzt mit pre-dependencies lösen, wovon ich aber abraten würde)

[Uwe_9988]

Hallo Targion,

das klingt ja sehr interessant.

Ich möchte jetzt keine größere Diskussion lostreten aber wenn Windows gegenüber Linux Vorteile hat, dann sicherlich bei der Installation von Software.


Grüße,
Uwe

[marcov]

Für Pascal-Scripte würden mich die anderen schlagen - es wird aber die möglichkeit geben, scripte auszuführen, zu verschiedenen Phasen der Installation. Die müssen dann aber in Bash geschrieben sein, da das au eigentlich jedem Linux-System vorhanden ist. Python wird vielleicht auch möglich werden, ebenso wie kompiliertes Zeug. (Obwohl wir da auch noch bedenken haben, da man bei binären Objekten nicht wissen kann, was genau sie tun.)
Also: InnoSettup ist im Grunde eine der Vorlagen (ebenso wie Apples Package-System) die wir im Blick haben, aber Funktionen ohne gründliche besprechung kopieren tun wir nicht ^^

Vorsicht, Debian hat vor ein paar Monate den default Shell von bash nach dash geändert. Wir haben schon der FPC Installer Script dafür korrigieren müssen

[marcov]

Daran ist natürlich gedacht, keine Sorge ^^ Das Projekt ist vom gesamten Design her auf Linux-Desktops ausgelegt, ich glaube auch nicht, dass jemand sowas auf dem Server haben will oder gar in eingebetteten Linuxsystemen. Die Vorraussetzungen für Scriptsprachen sind aber auch das geringste Problem. Die größten Probleme liegen in den Shared Libs und anderen Abhängigkeiten einer Anwendung sowie in darin, Software "relocatable" zu machen. (unerlässlich, um sie in andere Ordner zu installieren als eigentlich vorgesehen)
Das "Problem" (ich sehe das eigentlich als großen Vorteil) ist im großen und Ganzen, dass es das eine Linux an sich nicht gibt, sondern verschiedene Software-Kombis mit GNU/Linux als OS-Kern. (aber wofür haben wir die XDG, POSIX und die LSB, wenn nicht für einheitliche Standards?)
(Achja: Das Scriptproblem kann man schon jetzt mit pre-dependencies lösen, wovon ich aber abraten würde)

Nicht alle habe GNU/Linux als Kern. Typisch nur Debian Derivaten haben GNU/Linux am Kern. Die Übrige, wie Fedora haben einfach "Linux" am Kern.

[Targion]

Wird alles diskuiert Für die Interessierten verweise ich mal auf mein Blog zum Theme AppStream (mit weiterführenden Links)
Ein einheitliches Install-Format gehört nicht zum Primärfokus des Projektes, wird aber auch mit Sicherheit kommen.
Linux ist übrigens auch in Sachen Softwaremanagement viel besser als Windows - es war nur leider viel Potential ungenutzt über die Zeit. (Der Windows-Ansatz zur Softwareverwaltung ist IMO grottig, da ist Linux viel sauberer. Nur die Installation von 3rd-party software unter windows ist ein klein wenig besser geregelt)

[Uwe_9988]

Hallo Targion,

sagen wir mal so: Wenn Lieschen Müller Virtualbox auf WinXP und auf CentOs installieren muss, wo bekommt sie es wohl eher hin?

Mag sein, dass die Technik unter der Haube bei Linux besser ist. Im praktischen Einsatz ist bei Windows mittlerweile wesentlich weniger Wissen erforderlich als bei Linux. Mal von Ubuntu abgesehen, befindet man sich unter Linux noch deutlich zu oft in 'ner Konsole und muss kryptische Kommandos aus hoffnungslos veralteten HowTos abtippen. Man bekommt alles zum Laufen, klar. Aber der Weg ist manchmal schon sehr steinig.

Ein Installer, der auf vielen Distributionen funktioniert wäre auf jeden Fall ein Fortschritt. Noch besser wäre, wenn die verschiedenen Distributionen sich wieder einander annähern würden. Durch Standardverzeichnisse zum Beispiel. Illusorisch, oder?


Grüße,
Uwe