Von Fakten, Fakten ... am Mi, 25. Juli 2007 um 22:35 #
> Es ist trotzdem nur für rpm basierte Distributionen nützlich. > Denn es erstellt lediglich *.rpm Pakete. Ist also auch nicht allzuviel anders als der von canoncial.
Komisch - ich bin einer der inzwischen wohl 1000 Paketbauer, die beim openSUSE BuildService mitmachen - und ich kann sowohl RPM (*.rpm) als auf Debian (*.deb) Pakete damit bauen - aus einem Source Tarball wohlgemerkt.
...und im openSUSE Buildservice kann ich meine Pakete für 32- und auch für 64-Bit bauen lassen. Für Fedora, Mandrake, openSUSE, Debian _und_ Ubuntu. Sowie ich das in den letzten IRC Meetings mitbekommen habe, arbeiten die Leute bei Novell sogar daran auch für PPC bauen zu können. ...und wem das alles noch nicht reicht, der läd sich halt die Sourcen runter und macht seinen eigenen BuildService auf. Das sehe ich bei Cannonical derzeit nicht.
Auch wenn der openSUSE Buildservice derzeit noch ein paar kleinere Macken hat - so schnell werde ich sicherlich nicht wechseln. Immerhin habe ich ein Wiki, Mailinglisten, IRC-Meetings, ein Web- und einen Commandline-Client und eine Buildfarm an Rechnern, womit inzwischen schon "gebootstrapt" (also z.B. den Compiler sich selbst bauen lassen) werden kann. Auch von einem 1GB Limit ist bei openSUSE noch keine Rede (obwohl das bei weiterer Nutzung wahrscheinlich kommen wird).
Das einzige, was mir zu meinem Glück im Buildservice von SUSE noch fehlt ist die Einfachheit: derzeit muss ich sowohl dsc als auch specfile pflegen - aber ich hoffe, dass sich da noch etwas bewegt. Immerhin haben die SUSE Jungs in ihrer "Hackweek" mal gezeigt was sie sonst so drauf haben: innerhab einer Woche haben die sich 3000 Debian Pakete genommen und per Skript daraus RPMs bauen lassen! ...und zwar ohne Alien und gedöns - die haben direkt die dsc-Files analysieren und daraus spec-Files generieren lassen. Mein Wunsch zukünftig nur noch eine einzige Steuerdatei pflegen zu müssen um sowohl *.deb als auch *.rpm files zu generieren könnte also bald erfüllt werden.
...wenn da nur nicht dieses ewige "meine Distri hat aber alles in /opt/, meine in /usr" wäre. Wenn die Distris der LSB mehr Beachtung schenken und diese durch zusätzliche Regelungen aufwerten würden, wäre manches Paket ziemlich einfach zu portieren. Dabei fällt mir ein: für RPM-Specfiles gibt es ja Macros, die viele von diesen Sachen abfangen (so zeigt ein %_libdir bei SUSE einmal auf /usr/lib und bei einem 64-bit-Rechner auf /usr/lib64) - kann es sein, dass es so etwas bei Debian und Co. nicht gibt oder hab ich da was übersehen? Bislang packe ich dort jedenfalls alles unter /usr/lib - und möchte mir nicht vorstellen ob das wirklich funktioniert.
Immerhin: die Konkurrenz wächst auf allen Seiten. Was es für den Endnutzer (und in diesem Fall auch den freien Packager) angenehm macht
das: "(so zeigt ein %_libdir bei SUSE einmal auf /usr/lib und bei einem 64-bit-Rechner auf /usr/lib64)" sollte eigentlich nicht tragisch sein (ist aber ubuntu 7.04, nicht Novell (ex-SuSE)):
> Denn es erstellt lediglich *.rpm Pakete. Ist also auch nicht allzuviel anders als der von canoncial.
Komisch - ich bin einer der inzwischen wohl 1000 Paketbauer, die beim openSUSE BuildService mitmachen - und ich kann sowohl RPM (*.rpm) als auf Debian (*.deb) Pakete damit bauen - aus einem Source Tarball wohlgemerkt.
...und im openSUSE Buildservice kann ich meine Pakete für 32- und auch für 64-Bit bauen lassen. Für Fedora, Mandrake, openSUSE, Debian _und_ Ubuntu. Sowie ich das in den letzten IRC Meetings mitbekommen habe, arbeiten die Leute bei Novell sogar daran auch für PPC bauen zu können. ...und wem das alles noch nicht reicht, der läd sich halt die Sourcen runter und macht seinen eigenen BuildService auf. Das sehe ich bei Cannonical derzeit nicht.
Auch wenn der openSUSE Buildservice derzeit noch ein paar kleinere Macken hat - so schnell werde ich sicherlich nicht wechseln. Immerhin habe ich ein Wiki, Mailinglisten, IRC-Meetings, ein Web- und einen Commandline-Client und eine Buildfarm an Rechnern, womit inzwischen schon "gebootstrapt" (also z.B. den Compiler sich selbst bauen lassen) werden kann. Auch von einem 1GB Limit ist bei openSUSE noch keine Rede (obwohl das bei weiterer Nutzung wahrscheinlich kommen wird).
Das einzige, was mir zu meinem Glück im Buildservice von SUSE noch fehlt ist die Einfachheit: derzeit muss ich sowohl dsc als auch specfile pflegen - aber ich hoffe, dass sich da noch etwas bewegt. Immerhin haben die SUSE Jungs in ihrer "Hackweek" mal gezeigt was sie sonst so drauf haben: innerhab einer Woche haben die sich 3000 Debian Pakete genommen und per Skript daraus RPMs bauen lassen! ...und zwar ohne Alien und gedöns - die haben direkt die dsc-Files analysieren und daraus spec-Files generieren lassen. Mein Wunsch zukünftig nur noch eine einzige Steuerdatei pflegen zu müssen um sowohl *.deb als auch *.rpm files zu generieren könnte also bald erfüllt werden.
...wenn da nur nicht dieses ewige "meine Distri hat aber alles in /opt/, meine in /usr" wäre. Wenn die Distris der LSB mehr Beachtung schenken und diese durch zusätzliche Regelungen aufwerten würden, wäre manches Paket ziemlich einfach zu portieren. Dabei fällt mir ein: für RPM-Specfiles gibt es ja Macros, die viele von diesen Sachen abfangen (so zeigt ein %_libdir bei SUSE einmal auf /usr/lib und bei einem 64-bit-Rechner auf /usr/lib64) - kann es sein, dass es so etwas bei Debian und Co. nicht gibt oder hab ich da was übersehen? Bislang packe ich dort jedenfalls alles unter /usr/lib - und möchte mir nicht vorstellen ob das wirklich funktioniert.
Immerhin: die Konkurrenz wächst auf allen Seiten. Was es für den Endnutzer (und in diesem Fall auch den freien Packager) angenehm macht
"(so zeigt ein %_libdir bei SUSE einmal auf /usr/lib und bei einem 64-bit-Rechner auf /usr/lib64)"
sollte eigentlich nicht tragisch sein (ist aber ubuntu 7.04, nicht Novell (ex-SuSE)):
$ ll -d /usr/lib64
lrwxrwxrwx 1 root root 3 2007-04-21 11:19 /usr/lib64 -> lib
solange man darauf achtet, dass veraltete 32-bit SW anders benamst wird bzw. z.B. in /usr/lib32 Quarantäne gestellt wird.