bernarcher
Abiword macht immer mal wieder Probleme.
Gnumeric lohnt sich für komplexe Aufgaben. Aber ich brauche es kaum. Einfache Sachen mache ich nach wie vor im Terminal mit oleo (ein bereits recht altes ncurses-basiertes GNU Spreadsheet-Programm).
Meine Schreibarbeit erledige ich in Vim mit LaTeX.
Libre Office brauche ich fast nur noch zum Datenaustausch mit Windows-Leuten.
cipher
agaida schriebLibre durchgängig. Arch, aptosid, ubuntu, Win7. irgendwie gibt es wenig Alternativen, die das gesamte Spektrum abdecken. Ist zwar mit Kanonen auf Spatzen, da ich ungefähr 10 Dokumente im Jahr bearbeite. Aber zum mal was zusammenzählen ist die Tabellenkalkulation ganz nützlich. Ausserdem supporte ich Leute, die viel mehr schreiben als ich und die habe ich alle auf LibreOffice gehoben 😉
Begründung: Ich kann einfach Oracle nicht ab. Wenn ich eine Chance hätte, würde ich auch gerne auf MySQL und Sun-Java verzichten, kann ich aber leider nicht. Ich habe nichts dagegen, für Software Geld zu bezahlen oder aber, dass bestimmte Quellen closed source sind. Einzig und allein das Verhalten von Oracle geht mir tierisch auf den Sack.
Kann ich nachvollziehen.
Leider habe ich auch einige Software von mittlerweile Oracle die ich langfristig gerne los wäre. Zum Beispiel VirtualBox und halt OpenOffice und muss wohl auch noch irgendwann Java installieren, obwohl ich Java nicht mag. Habe nur noch keine Alternativen gefunden, die auf Windows und Linux laufen.
agaida
Ich hab noch mal ein wenig Hand aufgelegt. Die PKGBUILDS werden ja irgendwo in der Paketdatenbank abgelegt. Was passiert eigentlich, wenn man aus diesem PKGBUILD die Abhängigkeit rausnimmt? Dann hat doch Pacman nichts mehr zu nörgeln, da der Grund zum Nörgeln hart fehlt.
Ist nur eine Vermutung, in diesem Fall wäre ich ganz dreist und würde das Paket manuell forken und da einfach Abhängigkeit rauslöschen. Mit anderem Namen fällt das dann auch aus dem Update-Pfad raus, das würde es aber mit Kompilieren auch. Was dann noch funktioniert, funktioniert dann halt noch, was nicht mehr funktioniert, ist halt kaputt. Ist zwar richtig stumpf, so klappt das aber bei debian aber ganz vorzüglich.
cipher
Wenn ich mir das PKGBUILD so anschaue, ist es wohl mit einem einfachen rausnehmen aus der Abhängigkeit nicht getan sein. Da wird noch ne Menge kleinarbeit vonnöten sein. Leider fehlt mir im Moment die Zeit um da dran zubleiben. Außerdem habe ich nicht so viel Ahnung von der Erstellung von PKGBUILDs. Habe zwar ein paar erstellt, war aber nur Kleinkram.
libreOffice x86_64 - PKGBUILD
Wie schon geschrieben. Ich habe in der pacman.conf OpenOffice in die Ignore-Liste eingetragen (IgnorePkg). Jetzt kommt nur bei jedem Aufruf mehrere Warnungen "Ignoriere Paket-Ersetzung ...". Bin noch am suchen wie ich das Abschalte, das stört die Übersicht.
agaida
package_libreoffice() {
pkgdesc="a productivity suite that is compatible with other major office suites"
install=${pkgbase}.install
depends=("curl>=7.20.0" "hunspell>=1.2.8" "python2>=2.7" 'libwpd>=0.9.0' 'libxaw' "neon>=0.28.6"
'pango' 'nspr' 'libjpeg' 'libxrandr' 'libgl' 'dbus-glib' "icu>=4.6" 'libxslt'
'redland' 'libgraphite' 'hyphen' 'lpsolve' 'gcc-libs' 'sh'
'hicolor-icon-theme' 'desktop-file-utils' 'shared-mime-info' 'java-runtime' 'gtk2') # keep gtk2 for install script
Ist das Einzige, was ich als Runtime-Dependency entdecke.
cipher
agaida schrieb
package_libreoffice() {
pkgdesc="a productivity suite that is compatible with other major office suites"
install=${pkgbase}.install
depends=("curl>=7.20.0" "hunspell>=1.2.8" "python2>=2.7" 'libwpd>=0.9.0' 'libxaw' "neon>=0.28.6"
'pango' 'nspr' 'libjpeg' 'libxrandr' 'libgl' 'dbus-glib' "icu>=4.6" 'libxslt'
'redland' 'libgraphite' 'hyphen' 'lpsolve' 'gcc-libs' 'sh'
'hicolor-icon-theme' 'desktop-file-utils' 'shared-mime-info' 'java-runtime' 'gtk2') # keep gtk2 for install script
Ist das Einzige, was ich als Runtime-Dependency entdecke.
Naja was ich gesehen habe war in makedepends war nochwas und in build.
makedepends=( # makedepends
'boost' 'sane' 'perl-archive-zip' 'zip' 'unzip' 'xulrunner' 'unixodbc' 'hsqldb-java'
'apache-ant' 'gperf' 'poppler' 'kdelibs' 'gconf' 'cppunit'
'beanshell' 'vigra' 'libldap' 'lucene' 'libmythes' 'junit' 'libwpg' 'imagemagick'
# for additional ooo-build features
'mesa>=7.5' 'gstreamer0.10-base>=0.10.26' #'mono>=2.6.1'
#'saxon' - currently broken
# the depends from libreoffice main pkg
"curl>=7.20.0" "hunspell>=1.2.8" "python2>=2.7" 'libwpd>=0.9.0' 'libxaw' "neon>=0.28.6"
'pango' 'nspr' 'libjpeg' 'libxrandr' 'libgl' 'dbus-glib' "icu>=4.6" 'libxslt'
'redland' 'libgraphite' 'hyphen' 'lpsolve' 'gcc-libs' 'sh'
'hicolor-icon-theme' 'desktop-file-utils' 'shared-mime-info' 'java-runtime' 'gtk2') # keep gtk2 for install script
build() {
unset J2REDIR; unset J2SDKDIR; unset JAVA_HOME; unset CLASSPATH
[ -z "${JAVA_HOME}" ] && . /etc/profile.d/openjdk6.sh
[ -z "${MOZ_PLUGIN_PATH}" ] && . /etc/profile.d/mozilla-common.sh
[ -z "${ANT_HOME}" ] && . /etc/profile.d/apache-ant.sh
ich will da keinen Schnellschuss machen. Wenn dann muss ich mir Zeit nehmen, sonst wird das nichts. Da ist ja auch noch ein Patch- und Diff-File, muss ich auch nachschauen ob das was mit Java zu tun hat.
Vielleicht klappt das ja morgen oder am nächsten Wochenende. Die Woche über komme ich nicht dazu.
agaida
Auch wenn ich mich wiederhole, probiere doch einfach die binaries umzupacken und umzubenennen. Openoffice oder Libreoffice zu bauen ist die Hölle, das wurde hier schon mal erwähnt. Ich habe vor etwas über einem halben Jahr mal das unfertige Chakra getestet und brauchte meinen Satz an Werkzeugen. Leider gehörte OO dazu. Für diesen Mist habe ich auf einer sehr schnellen Maschine dann doch ca. 12 Stunden gebraucht, bis ich OO fertig hatte. Ich musste allerdings den ganzen Urschleim auch mitbauen, da von Arch klauen und für Chakra übersetzen, da vor der Verwendung von Arch-Binaries ausdrücklich gewarnt wurde.
Das hat echt keinen Spass gemacht. Aber ich will Dich nicht abhalten, vielleicht ist es ja besser geworden und es kommen nicht svn-Repositories von irgendwo angeflogen und alles baut auf Anhieb richtig. Das Build-Script von OO ist ja noch recht trivial, die Vorgänge, die dann abgehen, sind es nicht mehr.
Die makedepends und den Buildkram braucht man wirklich nur, wenn man braut. Für den täglichen Betrieb sind nicht mal alle deps erforderlich, die sind in diesem Falle nur dafür, dass pacman Futter hat. Wenn Du das Testen möchtest, dann installierst Du den Kram halt per pacman -Sd und gut ist. Dann merkst Du, an welchen Stellen es aussteigt.
cipher
@agaida:
Sorry, da habe ich wohl was falsch verstanden. Klar selbstbauen hatten wir schon, deshalb wollte ich das auch nicht übers Bein brechen.
Vielleicht kannst du mir auf die Sprünge helfen. Man lernt ja gerne was dazu.
Habe sowas noch nicht gemacht.
Welche Binaries meinst du, die aus den Paketquellen? Stehe gerade etwas auf der Leitung. Soll ich das pkg.tar.xz aus den Quellen ziehen und entpacken, oder meinst du die Binaries auf der libreOffice Website für Debian basierte Distri?
agaida
Ich hab das für arch noch nie auf diesem Weg gemacht. Grundlage für diese Idee war der Thread "Hacking Plymouth" auf uu.de. Ingo2 nimmt sich die debian-Pakete, dröselt die auf, editiert die debian/control und packt das Zeug wieder zusammen. Mit dem Kompilieren hat er es nicht so, wenn es auch einfacher geht. Wir haben uns mal ausfürlich über das Thema unterhalten.
Dieser Mechanismus müsste bei Arch auch gehen. Bei selbst gebauten Paketen, die Du mit pacman -U istalliert, checkt er die dependencies gegen den PKBUILD. Da liegt die Idee nahe, sich das PKGBUILD zu saugen und den fertigen Tar-Ball und das dann zu manipulieren. Ist halt nur so eine Idee.
Ich meine als wirklich die Sachen aus den Arch-Repositories.
cipher
Hört sich in jedem Fall interessant an. Muss ich mir mal anschauen, ob das funktioniert.
ich lade mir mal das PKGBUILD und den Tarball runter und schaue mal nach. das Problem ist nur das es nicht nur um ein Paket geht sondern durch die Abhängigkeiten mehrere Pakete eventuell nachgearbeitet werden müssen.
Habe mir jetzt den Tarball gezogen und entpackt. Kann ich nicht einfach die .PKGINFO anpassen, oder gibt es dann Probleme?
agaida
Ich glaube, dass hat sich mit dieser Technik auch erledigt. Die Pakete, die Du aus einem Source-Paket samt PKBUILD erstellst, sind ja im PKBUILD aufgelistet. Script machen, die entsprechenden Pakete saugen und gut ists gewesen. Ist halt nur so eine Idee. Das ist ja eindeutig zuordenbar, wer was steuert.
cipher
agaida schriebIch glaube, dass hat sich mit dieser Technik auch erledigt. Die Pakete, die Du aus einem Source-Paket samt PKBUILD erstellst, sind ja im PKBUILD aufgelistet. Script machen, die entsprechenden Pakete saugen und gut ists gewesen. Ist halt nur so eine Idee. Das ist ja eindeutig zuordenbar, wer was steuert.
Kann dir nicht ganz folgen.
Also ich habe mir jetzt mal das Installarchiv (libreoffice-3.3.2-2-x86_64.pkg.tar.xz) gezogen und entpackt. Darin ist ja die Datei .PKGINFO, kann ich die bearbeiten, dann mit tar wieder packen und installieren? Habe keine Ahnung ob das geht oder nicht. Will mir auch nicht meine Installation ruinieren. ich mache das auf dem Laptop das ich täglich benutze.
Kann ja auch sein das es keine gute Idee ist, ein Paket einfach so zu verändern. Wiil mir hier keinen Ärger einhandeln.
agaida
VBox? Ich würde mal sagen, die Antwort bei Problemen wäre ungefähr: Du hast es kaputtgemacht, sieh zu, wie Du es wieder ganz kriegst. Das Verändern von offiziellen Paketen sehe ich nicht so eng, wenn allen Beteiligten klar ist, dass bei möglichen Seiteneffekten keinerlei offizielle Unterstützung kommen wird.
Ich denke diese Modifikationen fallen in den Rahmen dessen, was mit Arch möglich ist. verbockst Du es, ist es Dein Ding, funktioniert es nicht, ist es Dein Ding, funktioniert Dein Weg, gibt es bestimmt ein paar Leute, die die Idee geil finden. Es ist halt nur nicht offiziell. Es ist ab dem Moment der Kaperung Deins.
http://www.archlinux.org/static/magazine/2008/newsletter-2008-Jun-02.html
Arch Is Not a Democracy
Every once in a while someone says that there should be a public vote on the way Arch Linux is run.
A common response is "Arch is not a democracy" In a democratic society, the majority opinion rules.
This is not the case in Arch. There has been a lot of majority opinion bouncing around in recent times
that is not ever going into the Arch Linux core as defined by the developers.
Arch is really a "Cooperative Anarchy". Anyone is free to do anything they like with Arch Linux,
excepting the few copyleft restrictions enforced by the GPL. This means that anyone who doesn't like
the current direction the Arch Linux development team is taking the distro can start their own
development team and run their version exactly the way they want to. Neither team would be
"more official" or "more legitimate" than the other. Ideally, this would occur with a certain level of
cooperation between the two (or multiple) teams, with no hard feelings, but this is not a requirement.
Thus, everyone can be satisfied and no vote excluding some users' opinions is required.
The Arch development team itself is a "Voluntary Oligarchy". The Arch developers have chosen to develop
this distro in a way that suits them. Nobody but the developers has input into what goes on in official Arch
development. This is their linux distribution and they have been kind enough to share it with the rest of the
world in case someone else likes it. The great thing for users, however, is that they get to choose whether
or not they are governed by this group of people.
Users that don't like the way Arch Linux is developed have two simple choices:
1. Use a different Linux distribution or operating system.
2. Develop Arch into what they want it to be.
As I mentioned last month, the second option does not require forking Arch. You can create custom
repositories of community contributed tools based on, but independent of the Arch Linux core. So next time
you think your voice should be heard in a democratic fashion, remember that you are already your own
personal Arch Overlord and are free to do with this distribution exactly what you wish.
cipher
OK, damit kann ich leben.
werde mir wohl eine VM installieren, um das ganze zu testen.
Wie schon gesagt, habe mir das Installarchiv gezogen und entpackt. In der .PKGINFO die Zeile "depend = java-runtime" auskommentiert, und wieder mit tar gepackt. Dann mit pacman -U versucht zu installieren. Sieht bis hierher gut aus, keine Java abfrage mehr.
Alles weitere dann wenn ich die VM installiert habe. Leider zur Zeit keine vorhanden. Muss also erst die komplette Installation machen mit gnome.
GerBra
Java brauchte man AFAIK bei OpenOffice lediglich für die Nutzung des Hilfesystems. Ohne Java (wenn z.B. mit --without-java oder ähnlichem kompiliert, weiß die Syntax nicht auswendig) keine Hilfefunktion.
agaida
Das mit der Installation sehe ich anders. Das ist ja richtig Arbeit. Kopier das doch einfach. Ein möglicher Weg wäre, von einer beliebigen CD zu starten, sich einen tar-Ball mit allem zu schrauben und irgendwo abzulegen. Dann erstellst Du eine VM und startest die auch mit dem Image der Live-CD. Sobald Du in der Maschine Netzwerk hast, kopierst Du den Tarball per scp oder so auf die virtuelle Platte und packst ihn aus.
Dann nur noch per chroot auf die Platte, fstab, hostname, evtl. ip und resolv.conf anpassen, mbr setzen, neu starten, glücklich sein.
Edit:
@GerBra - Reportgenerator u.Ä sollten dann auch nicht gehen, Writer und Calc wohl schon.
cipher
Ist eine gute Idee. Jedoch wollte ich die ganze Zeit schon eine VM mit archlinux haben um mal was testen zu können, habe mich nur davor gedrückt. Habe das dann aus Faulheit immer auf meinem System gemacht. Jetzt habe ich wenigstens einen Grund. 😉
Ich möchte jedoch auch testen können ob libreoffice sauber läuft bzw. ob es Probleme gibt, dafür brauche ich eine archlinux installation mit gnome. Die archlinux LiveCD hat ja keine grafische Oberfläche.
Oder habe ich dich falsch verstanden.
agaida
Ja. Nimm Dir debian, aptosid, ubuntu - halt irgendeine Distribution mit einer Live-CD. Von der bootest Du und hast ein Linux mit allem Schnickschnack (X, Gnome oder KDE je nach Geschmack). Das wichtige ist, dass deine Festplatte mit der Orginal-Installation nicht im Zugriff ist - wegen offenen Dateien. Das würde eine vernünftige Wartung ausschließen, wenn man sich an so was stört. 😉
Platte mounten und eine tar-Sicherung des gesamten Inhalts erstellen und irgendwo hinlegen, wo es nicht stört. Das wäre Schritt 1 - Arch gesichert.
Schritt 2. Vbox aufreissen, neue Maschiene mit Einstellunge Deiner Wahl anlegen. iso der LiveCD einbinden und die Maschine hochfahren. Das heisst explizit - nicht installieren. Jetzt kannst Du in der Live-Installation die virtuelle Platte des Systems ganz geruhsam vorbereiten (Partitionieren, formatieren).
Schritt 3. Ausgehend davon, dass die neue Platte genug Platz hat, das erstellte Archiv auf die virtuelle Platte kopieren und auspacken. Das Archiv auf der virtuellen Platte kannst Du dann löschen. Du hast ab diesem Zeitpunkt eine 1:1 Kopie Deiner Arch-Installation auf dem virtuellen Rechner.
Schritt 4. Anpassung des neuen Systems: Da Deine Kopie noch nicht lauffähig ist, musst Du noch tätig werden und ein paar Kleinigkeiten anpassen - fstab auf Deiner VM, das geht sonst schief. grub-install, das Ding soll ja auch gestartet werden können. resov.conf und ip-Settings, falls Du nicht DHCP fährst. Wenn Probleme mit dem Kernel auftauchen sollten, dann halt auch noch einen mkinitcpio laufen lassen (hab das ewig nicht mehr gemacht, sorry). Dazu benutzt man chroot.
Schritt 5: Neustarten und hoffen, dass man an alles gedacht hat.
Schritt 6: solange mit der CD rumfuckeln, bis man den letzten Haken erwischt hat.
Hab leider keine Anleitung dafür, da ich auf meinen Rechnern fast ausschließlich Installationen auf realer Hardware nutze, aber bis auf den Transfer auf die virtuelle Platte ist das ein ganz normaler Umzug einer bestehenden Linux-Installation auf eine andere Platte mit allem drum und dran. Eine VM ist ja auch nur ein ganz "normaler" Rechner, wenn man den Begriff "normal" ein wenig erweitert.
cipher
Achso, jetzt weis ich was du meinst. Ich soll mir ein Image von meinem System ziehen in die VM kopieren, entpacken und anpassen.
Sorry, habe mal wieder auf der Leitung gesessen. Dauert bei mir halt manchmal ein wenig länger ...
Denke mal bis ich das angepasst habe, mit Grafiktreiber und allem drum und dram habe ich auch neu aufgesetzt. Außerdem ist mein System schon stark verändert und ich möchte eine frische Installation haben. Will die Install dann auch nutzen um andere Sachen zu Testen, wenn mal wieder was spinnt. Zumal ich mittlerweile schon die Grundinstallation fertig habe. Muss nur noch xorg und gnome installieren.
Trotzdem Danke für die Anleitung. Ist ein guter Tip.
agaida
Na ja, an ein Image hab ich dabei nicht gedacht, ich vermeide dd, wann immer es geht. Ich bin zwar schon oft dafür ausgelacht worden (übrigens in verschiedenen Distributionen) aber meine Lieblingskombi auf allen Rechnern ist relativ gleich. /boot, swap, /lvm (unterm lvm eventuell noch ein raid) mit einem Debian-Verwaltungssystem. Spielsysteme erstell ich dann Distributionsunabhängig mit
lvcreate -L 20G --name testxy vgx/partitionsname
mkfs.ext4 -L partitionsname /dev/mapper/vgx-partitionsname
mount /dev/mapper/vgx-soruce /source
mount /dev/mapper/vgx-partitionsname /target
cp -ax /source/* /target
aus meinem Verwaltungssystem. Dauert so um die 5 min. Wenn ich so was öfter mache, baue ich vorher ein Installationstemplate. Die Zeit die man da reinsteckt, hat man beim 3. System wieder lang und schmutzig raus.
Mein Verschleiss an Installationen ist aber wahrscheinlich um Längen höher als Deiner. 😉