Red Hat hat einen modifizierten Compiler, der auf JEDEM, ich wiederhole, auf JEDEM Linux läuft.
Das gebaute Programm ist zu jeder Distribution binar-kompatibel.
Stört euch nicht am Red Hat!!!! Es ist bloß das einzigste, wo am Compiler div. Auflagen und Verbesserungen sind die die binar-kompatiblität fördern. Das gibt es bei keiner anderen Distribution.
Aber ich habe es eben ja schon gesagt:
- Gemerkere
- genörgle und
- völlig sinnlose Rückfragen
Tut mir wirklich leid, dass ich mich schon wieder einmische, aber...
Deine Pauschallösung geht von einigen Einschränkungen aus. Die Kompatibilität eines Pakets beinhaltet nicht nur die Binärkompatibilität der ausführbaren Datei. Wenn Du Deinen Anwendern wirklich was gutes mit dem Paket tun möchtest, willst Du u.a. wenigstens die zwei häufigsten Desktops mit Menüeinträgen versorgen. Und schon da gehen so ziemlich alle Distributionen weit auseinander. Ist doch auch nicht so schlimm, wenn man in virtuellen PCs mehrere Distris fährt und die Pakete zielgerichtet baut.
Taki, kein Thema, aber da liegst du leider nicht richtig.
Menüeinträge gehen bei KDE, wenn du die auf einen Nenner bringen willst immer unter ~/.kde/share/applnk
Ich gehe nur genau von der Frage aus, die lepsai stellte. Und ich weiß das es geht, denn eben nur (leier, leier) Red Hat hat genau diese Kompatiblität. Es ist kein großer Aufwand dabei und es geht sehr schnell.
Es kann genauso eine 100%ige Lösung sein, wie ein Distributionspaket.
Aber genau da haben wir auch schon wieder das Problem, ein SuSE Benutzer schreit nach einem rpm für seine SuSE Version 9.1 ein Paket für SuSE 9.1 läuft aber 100%ig nicht auf 8.1. Also nochmehr Pakete bauen! Was macht dann ein AMD64 User? Nochmal mehr Pakete bauen? Und das war dann nur SuSE.
Ich denke, das diese Distributionen bereits soweit auseinander sind (mehr kopf-technisch), dass die Anwender so drauf sind, dass Sie eben ein Paket für Ihre Distribution haben möchten.
Es gibt übrigens noch Autopackage und den Installer, den Mozilla.org nutzt, die sind genau dafür gedacht eben keine 100 Pakete zu bauen.
Teilweise finde ich das mit dem Nörgeln und Meckern schon schlimm, denn wenn ich ein Paket für alle bauen kann, warum zwingt mich ein User 100 Pakete zu bauen, was viel Zeit und Geld kostet? Logik?
Es ist gut, taki, dass du sagst was du denkst, aber ich wäre manchmal schon dafür sich vor dem abschicken Gedanken zu machen, was man jetzt eigentlich erzählt und wenn man es einfach nicht besser weiß vielleicht nix zu sagen.
Weitere Anmerkung:
VMWare kostet Geld, 5 Distributionspakete bauen kostet nicht nur sehr viel Zeit, sondern auch sehr viel Energie, denn jedes dumme Linux ist so anders, das selbst ein Paket von Debian sid auf sarge schon nicht mehr richtig gehen kann. Also die Paketbauerei ist nicht wirklich das wahre.
FlorianBecker hat geschrieben:Menüeinträge gehen bei KDE, wenn du die auf einen Nenner bringen willst immer unter ~/.kde/share/applnk
Ich möchte Dich wirklich nicht ärgern. Aber was Du sagst, geht wirklich nur bei Closed Source, die genau nur ein Anwender auf einer Maschine benutzen soll...
Meine Desktop-Dateien für KDE gehen für SuSE nach $KDEDIR/share/applnk, meine Icons nach $KDEDIR/share/icons/usw, mein Handbuch nach... Das kann ich noch weiter ausspinnen. $KDEDIR ist bei SuSE /opt/kde3, bei debian /usr, bei Red Hat /opt/kde (?) u.s.w.
Ich habe ja nichts dagegen, wenn ein Programm nur für den einen Benutzer gedacht ist und deshalb lokal installiert wird. Man muss es aber wissen und dazu muss man es aussprechen. Sonst denkt jeder, prima, ich habe eine Universallösung, und wundert sich über verärgerte Anwender, falls der eine globale Installation erwartet und die Verknüpfungen im Startmenü und u.U. auch Plugins nur beim User root funktionieren.
