RPMs DEPs und TGZ usw.. usw..

[HellTron]

Hi...

Wo liegt eigentlich das Problem das man DEPs RPMs und Sourcecode verreint ??? wiso kann mein Fedora nicht einfach alle drei ? ist das nicht etwas was es schon länger geben müsste ? einheitliches Paket System Linux übergreifend ? brauchen wir denn Verschiedene Systeme ?

Warum nicht eines was Binarys und Sourcen kann... dann mit yum und/oder apt-get zusammenschweissen und man macht ein

"apt-get install xine"
oder ein
"apt-get install form source xine"

??? Warum gibt es drei Verschiedene ? Ich will keines für besser befinden... besser wäre doch ein Einheitliches ... dagegen kann doch nichts sprechen oder ? auser wenn jammand natürlich gegen einen Standart ist und lieber ein Programm in Tausenden Paketen bereitstellen will damit jeder es nutzen kann ?/? der nich kompelieren will z.B.

oder lebe ich hinter dem Mond und es gibt das schon ????

[HEMIcuda]

Warum gibt es mehrere Distros, mehrere DMs/WMs, mehrere Mailserver,
mehrere Browser, mehrere <setz irgendwas ein>?

'cuda

P.S.: Hast Du Dir alien angeguckt?

[City][Sepp]

Nimm gentoo, da kannst bei emerge wählen, ob du aus den sourcen kompilieren möchtest oder fertige binärpakete installiert werden sollen (sofern vorhanden)...

[DarkSorcerer]

Jede Distro braut eben ihr eigenes Süppchen...

[yusuf75]

Hi

Slackware kann mit TGZ (das ist das eigentliche Paketformat) und mit rpm umgehen.

ausserdem wer braucht schon fertige Binarys ausser zum installieren des Grundsystemes ?

Ich saug prinzipiell immer alles als source und kompiliere es selber...
( KDE braucht 14 Stunden ;-)

[Susu]

Original geschrieben von HellTron
Wo liegt eigentlich das Problem das man DEPs RPMs und Sourcecode verreint Vorweg: Die Dinger heißen DEBs! *g* Das Problem dabei ist, dass Du dann mehrere Paketdatenbanken (rpm, deb, tgz) hättest und es wohl nicht so einfach ist, dieses kompatibel zueinander zu machen. Es gibt übrigens ne Distri, die das (angeblich) kann: Yoper

Ich wüsste aber ehrlich nicht, wozu man das brauchen sollte. Wenn ich ein Debian habe, dann reichen die DEBs doch wohl aus (glaube, die haben das größte Paketangebot unter den Distris), ansonsten kompiliert man halt oder sucht im Netz nach Binary-Paketen. Gleiches gilt für rpm-basierte Distris. Wieso sollte ich das alles mischen wollen?

Man sucht sich ne Distri aus, die einem am besten gefällt (und/oder dessen Paketmanagement man für gut befindet) - und fertig!

Susu

P. S. Ich persönlich würde es blöd finden, wenn alle Distris das gleich Paketsystem haben - es würde mir meine Freiheit nehmen... Denn dann bräuchten wir ja eigentlich auch nur noch EINE Linux-Distri...

[Susu]

Original geschrieben von HEMIcuda
P.S.: Hast Du Dir alien angeguckt? Der Weg über alien - egal bei welcher Distri auch immer - halte ich für äußerst unelegant. Außerdem kann man da auch gleich selbst kompilieren...

Susu

[Thomas Engelke]

Original geschrieben von Susu
... Außerdem kann man da auch gleich selbst kompilieren ...

Dann deinstallier' mal ohne Paketmanagement. Nur die wenigsten Pakete haben doch ein "make uninstall".

Das Problem ist wohl gar kein Problem. wie überall bei Linux hast du massig Alternativen. Warum sollte man alles vereinen und an einem Strang ziehen, wenn Linux aufgrund seiner Struktur doch die Möglichkeit bietet, jedem die Verarbeitung anzubieten, die er gerne hätte. Man sollte, wenn man überhaupt an diesem Punkt arbeitet, daran arbeiten, daß ein Paketmanagementsystem immer an eine Distribution gekoppelt ist.

AD!

[DarkSorcerer]

Beim ATI-Treiber hat man da weniger Chancen... oder gibt es ein deb-Paket für den ATI Treiber? Bei gentoo kann ich diesen wunderbar emergen, genauso auch den nvidia treiber. bei debian muss man dann leider über "alien" gehen.

[Thomas Engelke]

Original geschrieben von DarkSorcerer
... den nvidia treiber. bei debian muss man dann leider über "alien" gehen.

Sicher? Es gibt doch ein Paket dafür. Dieses lädt dann den Treiber von nVidia runter und kompiliert ihn. Alles läßt sich hinterher mittels dpkg wieder deinstallieren. Oder hat sich Debbie so geändert, seitdem ich weg bin?

AD!

[DarkSorcerer]

Ich konnte damals keins finden.

Hier noch ein Auszug aus gmpf.de



Besonderheit Debian: Debian verwendet keine RPM sondern DEB-Pakete. Die Datei fglrx-glc22-4.3.0-3.2.0.i586.rpm muss deshalb mit dem Tool alien in ein DEB-Paket konvertiert werden. Der Befehl hierzu lautet: alien fglrx-glc22-4.3.0-3.2.0.i586.rpm (Hinweis: alien ist oft nicht installiert. In diesem Fall muss es zuerst mit apt-get install alien eingespielt werden). Anschließend kommt die Datei fglrx-glc22-4.3.0-3.2.0.i586.deb heraus. Dieses Paket lässt sich anschließend mit dem Befehl dpkg -i fglrx-glc22-4.3.0-3.2.0.i586.deb einspielen.


Da ist nicht die Rede von einem debian package für den ATI Treiber... von daher denke ich das es noch keinen gibt...

[Thomas Engelke]

Original geschrieben von DarkSorcerer
Da ist nicht die Rede von einem debian package für den ATI Treiber... von daher denke ich das es noch keinen gibt...

Nunja, wie an meinem Post eindeutig zu ersehen, bezog ich meine Aussage auf den nVidia-Treiber. Bei ATI kann ich nichts sagen, hab' bisher keine solche Karte.

AD!

[DarkSorcerer]

Ack so, dann war ich in Gedanken schon bei einem anderen Thread in dem es um den ATI Treiber auf einem Debian System und "alien" ging :)

[zander]

Das Problem mit alien ist meistens nicht, daß die Paketformate problematisch sind (es handelt sich z.B. nur um modifizierte cpio und ar Archive), sondern um die unterschiedlichen Vorstellungen der Distributoren hinsichlich Dateisystemkonventionen, Konfigurationsmechanismen und ähnlichem. Zwischen diesen übersetzen zu wollen würde unverhältnismäßigen Einsatz erfordern. Üblicherweise werden Softwarepakete von Distributoren auch nicht 1:1 übernommen, sondern diverse Veränderungen (distributions-spezifische und generische) vorgenommen, bevor das eigentliche Paket erstellt wird. Die ursprünglichen Quellen und die vorgenommenen Veränderungen sind allerdings erhältlich, bei Debian GNU/Linux z.B. über den apt-get source Mechanismus.

Es kann durchaus notwendig sein, auf diese Quellpakete zurückzugreifen um möglichs einfach distributions-konforme Pakete erstellen zu können.

Insofern diese Notwendigkeit nicht besteht ist das Übersetzen sämtlicher Systemkomponenten auf dem heimischen PC ein netter Zeitvertreib für all diejenigen, die nichts sinnvolles mit ihrer Zeit oder der ihres Rechners anzufangen wissen. ;)

[zander]

Als Anmerkung zu den NVIDIA Treibern und alien: es war noch nie notwendig (oder sinnvoll), die von NVIDIA bereitgestellten RPM Archive mit diesem Hilfsprogramm in .deb Pakete zu übersetzen und diese zu installieren.

[Susu]

Original geschrieben von Thomas Engelke
Dann deinstallier' mal ohne Paketmanagement. Nur die wenigsten Pakete haben doch ein "make uninstall" Naja, eine Paketdatenbank ist ja sowohl bei rpm, deb als auch tgz vorhanden. Selbstkompilierte Paket installiert man mit checkinstall und dann stehen sie auch in der Paketdatenbank drin. Demgemäß bekomme ich sie auch ganz einfach wieder herunter - oder seh ich da was falsch...

Susu

[Susu]

Original geschrieben von DarkSorcerer
bei debian muss man dann leider über "alien" gehen. Hä? Wieso das? Man lädt sich den Treiber (diese *.run-Datei) von Nvidia runter, und installiert den Treiber, wie ich es in DIESEM TUT (http://www.linuxforen.de/forums/showthread.php?s=&threadid=106033) unter Punkt 7 beschrieben habe. Wozu brauch ich da ein fertiges DEB?

Susu

[zander]

Die NVIDIA Treiber werden erst seit relativ kurzer Zeit als selbstentpackendes Archiv mit Installationsprogramm vertrieben, ursprünglich hat NVIDIA tar Archive sowie RPM/SRPM Dateien bereitgestellt. Zu dieser Zeit war die Installation der durch dritte erstellten .deb Pakete für viele Benutzer komfortabler.

[DarkSorcerer]

Original geschrieben von Susu
Hä? Wieso das? Man lädt sich den Treiber (diese *.run-Datei) von Nvidia runter, und installiert den Treiber, wie ich es in DIESEM TUT (http://www.linuxforen.de/forums/showthread.php?s=&threadid=106033) unter Punkt 7 beschrieben habe. Wozu brauch ich da ein fertiges DEB?

Susu

ne ne ne ne... ich meinte _nicht_ den nvidia treiber sondern den ATI treiber...
scheint wohl ein kleines missverständnis zu sein :)

[-hanky-]

Original geschrieben von yusuf75
Hi

Slackware kann mit TGZ (das ist das eigentliche Paketformat) und mit rpm umgehen.

ausserdem wer braucht schon fertige Binarys ausser zum installieren des Grundsystemes ?

Ich saug prinzipiell immer alles als source und kompiliere es selber...
( KDE braucht 14 Stunden ;-)

Hi,

leicht OT ( passt aber auch zum Thema ) : Kennst du checkinstall ? Das ist genial.

./configure, make und danach ein checkinstall - Voila, aus den Sourcen kompiliert und per Slackware-Paketmanagement installiert und so jederzeit restlos löschbar.

Checkinstall kann übrigens auch mit .deb und rpm-Paketen umgehen. Vielleicht einfach mal anschauen. Ich finde das Tool ist völlig zu Unrecht so unbekannt :)

-hanky-

[flashbeast]

also das einzige was ich mir wünsche ist dass tgz's so einfach zu installieren sein sollen wie rpm's, also mit dem spzifischen paketsystem gekoppelt werden.

derzeit installiere ich eigentlich ausschließlich über 'urpmi', nur gibt es nicht zu jedem programm rpm's für z.b. mandrake, und da sollte man (wie bei checkinstall) tgz's genauso behandeln können wie rpms', z.b.:

urpmi programm
precompiled programm not found. download and install tarball? y/n
loading...
installing...
done.

nur so als beispiel...
bzw. direkt die datei angeben kann: 'urpmi programm.tgz' usw....

[sirmoloch]

Was hindert dich daran ein eigenes Paketsystem zu erstellen??? Selbst wenn du nur das Design erstellst findet sich bestimmt jemand, der den Rest übernimmt.

Bitte jetzt nicht meckern, aber an Computern kann halt jeder alles machen...;) :ugly:

[zander]

Die Entwicklung eines weiteren Paketmanagement-Systems fiele wohl in die Kategorie "Projekte, die die Welt nicht braucht".

[sirmoloch]

Original geschrieben von zander
Die Entwicklung eines weiteren Paketmanagement-Systems fiele wohl in die Kategorie "Projekte, die die Welt nicht braucht".

Das ist eine andere Frage. Aber wenn es jemandem etwas nicht passt, gibt es zwei Möglichkeiten:

1. Die vorhandenen Möglichkeiten akzeptieren.
2. Eine neue Lösung erstellen.

[Susu]

Original geschrieben von zander
Die Entwicklung eines weiteren Paketmanagement-Systems fiele wohl in die Kategorie "Projekte, die die Welt nicht braucht". Full ack! Wir haben doch schon 3 Paketformate, wozu noch mehr?

Susu

[zander]

Grundsätzlich stimme ich Dir zu, aber die Tatsache, daß im GNU/Linux Umfeld lange Zeit lang jeder sein eigenes Süppchen gekocht hat (und nicht selten immer noch kocht), hat zu einer Fragmentation geführt, die mitunter auch als Segen, mehrheitlich aber als Manko angesehen wird. Anstatt weiteres Flickwerk zu produzieren sollte man lieber in Erwägung ziehen, Projekte wie LFS/LSB zu unterstützen um diese Art von Problem einheitlich in den Griff zu bekommen.

[flashbeast]

Original geschrieben von zander
Die Entwicklung eines weiteren Paketmanagement-Systems fiele wohl in die Kategorie "Projekte, die die Welt nicht braucht".
es geht nicht um ein neues paketformat. vielmehr geht es darum, binär- und quellcode-pakete zusammenzuführen, z.b. rpm's und tgz; momentan geht es wohl schon per checkinstall.

was ich aber will ist ein einfacheres system wie das von mir oben dargestellte beispiel. es ist kein richtiges system als vielmehr ein programm, dass mehrere programme unter einen hut bringt. verbunden mit einem grafischen frontend und dicken servern wo die dateien lagern würde es imho den kritikpunkt "paketabhängigkeiten" bzw. "schwierige softwareinstallation" in rauch aufgehen lassen...


Original geschrieben von zander
Was hindert dich daran ein eigenes Paketsystem zu erstellen??? Selbst wenn du nur das Design erstellst findet sich bestimmt jemand, der den Rest übernimmt.
ich bin mir sicher dass es schon mehrere ansätze gegeben hat (emerge), aber ich werd's (später) mal probieren und schauen ob überhaupt interesse besteht ;)

[sirmoloch]

Original geschrieben von zander
Grundsätzlich stimme ich Dir zu, aber die Tatsache, daß im GNU/Linux Umfeld lange Zeit lang jeder sein eigenes Süppchen gekocht hat (und nicht selten immer noch kocht), hat zu einer Fragmentation geführt, die mitunter auch als Segen, mehrheitlich aber als Manko angesehen wird. Anstatt weiteres Flickwerk zu produzieren sollte man lieber in Erwägung ziehen, Projekte wie LFS/LSB zu unterstützen um diese Art von Problem einheitlich in den Griff zu bekommen.

Ich bin 1000% deiner Meinung! Im Umfeld von Linux sollte alles mehr standarisiert werden.

Nur wie gesagt, es ging darum, dass man sich ja beschweren kann wie man will. Wenn man meint es ginge besser soll man es ruhig machen und wenn er jetzt z.B. einen Paketmanager schreiben würde, der RPM, DEB und tgz unterstützt wäre das doch wunderbar. :ugly::ugly:

[zander]

Pakete wie RPM oder DEB beinhalten neben den eigentlichen Nutzdaten eine Reihe von Informationen, deren Format und Umfang durch Konventionen festgelegt ist und die nur für den jeweiligen Paketmanager von Interesse sind; dieser kann aber wiederum auf die Informationen angewiesen sein um korrekt zu funktionieren.

Normale tar Archive (.tar, .tar.gz, .tgz, ...) sind zunächst einfach nur Ansammlungen von Daten; es ist für außenstehende nicht ersichtlich, um welche Art von Daten es sich handelt. Selbst wenn man einschränkend annähme, daß man es mit Quellen für ein Softwarepaket zu tun hat, ist daraus noch lange nicht ersichtlich, wie diese übersetzt und installiert werden müssen, von der Einbindung in bestehende Systeme und Informationen zu Abhängigkeiten ganz zu schweigen. Es ist einfach nicht sinnvoll (bzw. (falls überhaupt) mit vertretbarem Aufwand möglich), all diese Probleme auf automatischem Wege zu lösen.

[zander]

Was hindert dich daran ein eigenes Paketsystem zu erstellen??? Selbst wenn du nur das Design erstellst findet sich bestimmt jemand, der den Rest übernimmt. hat übrigends sirmoloch geschrieben. ;)