RootForum Community

Hoi!

Hab ich grade zufällig gelesen, und finde es durchaus bemerkenswert: IBM DB2 wurde kürzlich für Ubuntu zertifiziert, und somit erstmalig für eine nicht-RPM Distribution (DB2 ist ja nur als RPM erhältlich!).

Details: http://www.ubuntulinux.org/newsitems/db2cert

Darüber hinaus habe ich bei der Gelegnheit noch bemerkt, dass das DB2-HOWTO auf tldp.org kräftig überarbeitet wurden ist, und jetzt neben Ubuntu auch eine Installations-Anleitung für Gentoo enthält: http://tldp.org/HOWTO/DB2-HOWTO/

Und auch die neue (kostenlose) Oracle XE lässt sich auf Gentoo installieren: http://forums.gentoo.org/viewtopic-p-28 ... ml#2864721

Was mich interessieren würde - hat es irgendeinen Nachteil wenn man das so installiert, gegenüber der Installation per RPM in einer RPM-basierten Distribution? Gut, deinstallieren und upgraden ist vielleicht etwas umständlicher, aber vom Betrieb her dürfte es doch keine Probleme geben, oder? Oder könnte es passieren, dass Abhängigkeiten die ja möglicherweise fehlen, sich erst im Betrieb auswirken? Unterm Strich ist doch beides Linux, egal welche Distribution. Und wenn man auf entsprechend empfohlene glibc-Versionen und ähnliches achtet - da sollte das doch kein Problem sein, oder?

Sorgen mache ich mir nur um unterdrückten Abhängigkeiten...

edit:
Theoretisch müsste man da eigentlich auch ebuilds für schreiben können, oder? Hab auch eines für ZendOptimizer erstellt, und da ist das ja rechtlich und praktisch dasselbe Problem (wg. Lizenz manuell runterladen, binäres Paket), der Unterschied ist lediglich die Verwendung von RPM. Könnte man ja als Abhängigkeit machen - also warum nicht?

Grüße
Andreas

PS: Ich weiß dass es gute Opensource-Alternativen gibt..., finde es trotzdem bemerkenswert!

Ich denke das sollte nicht das Problem darstellen. Es gibt ja im Portage eine Menge dieser ebuilds mit den dort genannten fetch_restrictions also das manuelle herunterladen des Packetes. Auch für RPM packete kennt gentoo ja bereits eine Lösung. Bei Nero Linux war das eine Zeit lang so das man manuell das rpm herunterladen musste um dann das ebuild korrekt zu installieren. VMware fällt mir da spontan auch noch zu ein...

Ah, interessant, bei vmware habe ich zwar nichts mit rpm gefunden, dafür aber bei nero und einigen anderen (acroread, icc, realplayer, ati-drivers, openoffice-bin...).

Die verwenden soweit ich das sehe eine rpm.eclass

Allerdings verwenden die nicht den RPM-Befehl selbst (wie die Anleitungen für Oracle und DB2), sondern entpacken das Archiv, und installieren das dann "manuell". Ist jetzt die Frage was mehr Sinn macht. rpm selbst für die Installation zu verwenden ist sicher einfacher, allerdings hat man bei Verwendung der eclass natürlich die volle Kontrolle über die installierten Dateien in Portage - dafür eben auch mehr Arbeit. Oder meinst Du man sollte lieber den rpm-Befehl direkt verwenden?

falls es jemanden interessiert, ich habe mal den kompletten Portage-Tree durchsucht, und folgende Pakete verwenden die rpm.eclass:

andreask2 wrote:Ist jetzt die Frage was mehr Sinn macht. rpm selbst für die Installation zu verwenden ist sicher einfacher, allerdings hat man bei Verwendung der eclass natürlich die volle Kontrolle über die installierten Dateien in Portage - dafür eben auch mehr Arbeit. Oder meinst Du man sollte lieber den rpm-Befehl direkt verwenden?

Wenn das RPM nur ein "besseres" Archiv für das Programm ist, spricht nichts dagegen, einfach nur rpm2targz (bzw. die eclass, die das automatisiert) zu verwenden.
Gerade im Fall von Oracle XE läuft aber bei dem RPM noch ein %pre-Skript, das einige Ã?nderungen am System vornimmt und ohne das Oracle nicht läuft. Das, was das %pre-Skript macht, müsste dann der ebuild übernehmen und das ist (aus eigener Erfahrung) ein riesen PITA.