noisefloor
Ehemaliger
Anmeldungsdatum: 6. Juni 2006
Beiträge: 28954
Wohnort: WW
|
Hallo,
Das ist ja eine weitere Überraschung für mich, denn die Snap-Versionen sind ja über Ubuntu/Programme/.. installierbar und ich ging bisher davon aus, dass alle dort angebotenen Programme über die zentrale Paketverwaltung ständig aktualisiert werden und somit auch qualitäts- / sicherheits-geprüft sind
Dein Problem ist alleine deine falsche Erwartungshaltung. Hat ein Programm einen Bug, dann ändert keine Paketverwaltung daran was. Egal ob DEB, RPM, snap oder was auch immer. Bzgl. snap: auch du kannst snaps bauen und im snap-Store hochladen. Wenn du jetzt ein snap für Version X.Y baust, zwingt dich _niemand_, ein snap für Version X.Z zu bauen, sobald diese verfübar ist. Das ist reine Eigenmotivation (und deine Zeit). Wenn du garantiert immer die aktuelleste Version haben willst, ist selber kompilieren (mit all' seinen Nachteilen) die sicherste Wahl. Gruß, noisefloor
|
Bournless
Anmeldungsdatum: 4. Mai 2019
Beiträge: 915
|
Wenn du garantiert immer die aktuelleste Version haben willst, ist selber kompilieren (mit all' seinen Nachteilen) die sicherste Wahl.
Sollte evtl. hier (in diesem Forum) mal näher erklärt werden, wie man das grundasätzlich machen kann!?
Nicht in der Form eines WIKI-Artikels, sondern in der Form von konkreten Beispielen. Also eine Art Themen-HowTo.
|
Thomas_Do
Moderator
Anmeldungsdatum: 24. November 2009
Beiträge: 8493
|
Bournless schrieb: Wenn du garantiert immer die aktuelleste Version haben willst, ist selber kompilieren (mit all' seinen Nachteilen) die sicherste Wahl.
Sollte evtl. hier (in diesem Forum) mal näher erklärt werden, wie man das grundasätzlich machen kann!?
Dazu gibt es einen Wiki-Artikel.
Nicht in der Form eines WIKI-Artikels, sondern in der Form von konkreten Beispielen. Also eine Art Themen-HowTo.
Und für wie viele Programme soll man das machen? Das ist für jeden Quelltext etwas anders. Außerdem ist ein Beispiel kurze Zeit später nicht mehr aktuell und nachvollziehbar, weil sich zum Beispiel die Ahhängigkeiten geändert haben. Ich finde den o.g. Wiki-Artikel durchaus aussagekräftig. Einfach einmal selbst an einem Beispiel probieren und bei konkreten Problemen hier nachfragen. Es sollte aber auch klar sein, dass selbst kompilieren nicht wirklich "benutzerfreundlich" ist und auf jeden Fall die Bereitschaft erfordert sich mit der Technik und dem jeweiligen Programm zu beschäftigen.
|
Bournless
Anmeldungsdatum: 4. Mai 2019
Beiträge: 915
|
...Außerdem ist ein Beispiel kurze Zeit später nicht mehr aktuell und nachvollziehbar, weil sich zum Beispiel die Ahhängigkeiten geändert haben.
Ja, ok. Das ist ein ausschlagendes Argument. Ich habe da wohl nicht zu weit (mit) gedacht.
|
noisefloor
Ehemaliger
Anmeldungsdatum: 6. Juni 2006
Beiträge: 28954
Wohnort: WW
|
Hallo, @Bournless: ob man sich das mit dem Kompilieren wirklich geben will, ist ein eigenes Thema... 😉 Aber grundsätzlich ist das der Weg, wo man am detailliertesten bestimmen kann, wie und was wohin auf die Platte kommt. Wenn du eine Praxisbeispiel aus dem Wiki möchtest: Python/manuelle Installation Gruß, noisefloor
|
seahawk1986
Anmeldungsdatum: 27. Oktober 2006
Beiträge: 11176
Wohnort: München
|
Ich würde ja nach Möglichkeit den extra Schritt gehen und ordentliche Debian-Pakete bauen (das ist leider noch mal eine Stufe spezieller, aber immerhin recht brauchbar dokumentiert: https://www.debian.org/doc/manuals/maint-guide/) - Ubuntu stellt dankenswerterweise aus genau dem Grund die Möglichkeit für PPAs zur Verfügung (https://help.launchpad.net/Packaging/PPA), so dass man selbst gebaute Pakete dann bequem auf beliebig vielen Rechnern nutzen kann. Wenn man die Paketquellen für die Quellpakete auf seinem System aktiviert hat (deb-src Einträge), kann man sich mit apt source PAKETNAME die Quellen der Vorgängerversion holen und das debian-Verzeichnis daraus als Ausgangspunkt für eine neue Paketversion nutzen. Wenn man sich dafür interessiert, welche Schritte zum Bauen von bestimmten Paketen nötig sind, ist es oft hilfreich sich anzusehen, wie das z.B. für die Pakete von Arch Linux gelöst ist - im Gegensatz zu Ubuntu/Debian wird da nichts hinter debhelper-Automatismen versteckt, sondern man sieht im PKGBUILD alle Quellen, nötigen Schritte usw. - hier mal für die aktuelle LibreOffice-Version: https://git.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/libreoffice-fresh
|
Clemens-XS
(Themenstarter)
Anmeldungsdatum: 4. April 2015
Beiträge: 281
|
OK, ich komme also leider nicht um die Beschäftigung mit den Snaps herum. Denn ich sehe, dass etwa seit Beginn 2019 Programme, die bisher in den Ubuntu-Quellen als normale Pakete vorlagen, sukzessive durch Snaps ersetzt werden. Und sobald sie ersetzt worden sind, werden die bisherigen Pakete nicht mehr aktualisiert. Das war bei LibreOffice und Nextcloud und KeePassXC zu beobachten. Also bin ich gezwungen, entweder die bisherigen Pakete über Fremdquellen zu beziehen und zu aktualisieren (Sicherheit!) oder ich muss Snaps wählen, weil die alle aus der Ubuntu-Paketverwaltung kommen. DAS ist mein Haupt-Ärger, weil ich mich genötigt fühle, etwas zu installieren, das mir einen Haufen Zusatzaufwand bereitet, mir die Zeit stiehlt und auch offensichtlich nicht richtig funktioniert! Und wie kann ich nun eine Connect-Regel erstellen, aufgrund der mein LibreOffice-Snap auf ein Verzeichnis innerhalb des Nextcloud-Snap schreibend. lesend und löschend zugreifen darf? Ich habe hier sorgfältig nachgelesen und das Prinzip verstanden, aber nicht, wie nun die Syntax aussehen muss. Lasse ich mir alle Connects von LibreOffice anzeigen:
$ snap connections libreoffice
Interface Plug Slot Notes
bluez libreoffice:bluez - -
content[gnome-3-28-1804] libreoffice:gnome-3-28-1804 gnome-3-28-1804:gnome-3-28-1804 -
content[gtk-3-themes] libreoffice:gtk-3-themes gtk-common-themes:gtk-3-themes -
content[icon-themes] libreoffice:icon-themes gtk-common-themes:icon-themes -
content[sound-themes] libreoffice:sound-themes gtk-common-themes:sound-themes -
cups-control libreoffice:cups-control :cups-control -
desktop libreoffice:desktop :desktop -
gsettings libreoffice:gsettings :gsettings -
home libreoffice:home :home -
network libreoffice:network :network -
network-bind libreoffice:network-bind :network-bind -
opengl libreoffice:opengl :opengl -
pulseaudio libreoffice:pulseaudio :pulseaudio -
removable-media libreoffice:removable-media :removable-media -
screen-inhibit-control libreoffice:screen-inhibit-control :screen-inhibit-control -
unity7 libreoffice:unity7 :unity7 -
wayland libreoffice:wayland :wayland -
so finde ich keinen existierenden Plug von LibreOffice, wo ich das Verzeichnis Templates mit dem Datenverzeichnis von Nextcloud verbinden kann. Auch die obige Zeile home libreoffice:home :home hilft mir dabei kaum weiter, obwohl sich home ja wohl auf das jeweilige home-Verzeichnis bezieht. Hat jemand hier bereits mit Connect-Regeln gearbeitet und kann mir sagen, wie z.B. diese Regel erstellt werden muss? Und was bedeutet es, wenn in der Spalte "notes" der Vermerk "manual" steht?
|
seahawk1986
Anmeldungsdatum: 27. Oktober 2006
Beiträge: 11176
Wohnort: München
|
Laut https://curius.de/blog/13-betriebssysteme/open-source/446-exkurs-nextcloud-als-snap-installieren kann man das nextcloud-Snap dazu bringen die Nutzdaten außerhalb des Snap-Verzeichnis zu speichern. Soweit ich das verstanden habe, wären z.B. /home/nextcloud oder /media/Daten/nextcloud eine Möglichkeit, auf die andere Snaps zugreifen können wenn sie die Zugriffsrechte für :home bzw. :removable-media haben.
|
Clemens-XS
(Themenstarter)
Anmeldungsdatum: 4. April 2015
Beiträge: 281
|
@seahawk1986: Der von dir verlinkte Beitrag bezieht sich aber auf die Installation eines Nextcloud-SERVER als Snap und nicht als Client. Ich habe hier meine Probleme mit dem Client und dem darüber synchronisierten Datei-Verzeichnis, in dem auch die Templates liegen. Aktuell habe ich drei Linux-PCs und ein Smartphone, die auf meinen Nextcloud-Server (im Internet auf einem Webspace installiert) zugreifen, sowohl was Kontakte, Aufgaben und Kalender als auch was Dateien wie z.B. KeePass-Datenbank oder eben die Templates betrifft. Sobald ich von einem Client etwas ändere, ist es bei den anderen Geräten ebenfalls synchronisiert. Mir ist bekannt, dass ich über fstab auch das Nextcloud-Dateiverzeichnis auf dem Server als Netzlaufwerk einbinden kann. Dazu muss man sich aber beim Mounten mit Passwort einloggen = sehr lästig, zumal zu diesem Zeitpunkt KeePassXC noch nicht als Gedächtnisstütze für das z.B. 24-stellige Passwort zur Verfügung steht. Ein Auto-Login ist zwar durchaus möglich, habe ich aber noch nie zum Laufen bekommen. Ferner fokussieren wir hier jetzt zu sehr auf Nextcloud. Nextcloud ist ja nur EINE Baustelle. Bisher läuft bei mir KeePassXC nur deshalb noch reibungsfrei, weil ich mit der alten Version arbeite, also noch nicht als Snap. Angesichts der bis jetzt schon ersichtlichen Probleme habe ich mich dafür entschieden, KeePassXC-Snap noch nicht zu verwenden. Oder nehmen wir andere Programme, die z.B. die Scanner-Schnittstelle benutzen können, wie LibreOffice, GIMP usw. Ich hatte, wie schon erwähnt, gewaltige Probleme, den Scanner meines relativ neuen Samsung-Multifunktionsdrucker von besagten Programmen aus benutzen zu können (riesige Diskussion hier im Forum dazu). Ich befürchte sicher zu Recht, dass das jetzt Erreichte, nämlich die halbwegs hergestellte Scanner-Funktionalität durch den Snaps-Irrsinn wieder verloren gehen könnte und ich erneut wochenlang basteln und hier diskutieren darf, statt dass ich dazu komme, mit den PCs meine Alltagsarbeit erledigen zu können. Ich verstehe immer mehr, dass auch heute noch Linux-PCs oft nicht als ernstzunehmende Arbeitsmittel, sondern als Bastel-Selbstzweck für Nerds betrachtet werden!
|
seahawk1986
Anmeldungsdatum: 27. Oktober 2006
Beiträge: 11176
Wohnort: München
|
Clemens-XS schrieb: @seahawk1986: Der von dir verlinkte Beitrag bezieht sich aber auf die Installation eines Nextcloud-SERVER als Snap und nicht als Client.
Das wäre hilfreich, das auch zu schreiben... - einen über Snap installierbaren offiziellen nextcloud-Client sehe ich jetzt nicht, der Hersteller bietet ein Appimage (https://nextcloud.com/install/#install-clients) und ein PPA (https://launchpad.net/~nextcloud-devs/+archive/ubuntu/client) an.
|
seahawk1986
Anmeldungsdatum: 27. Oktober 2006
Beiträge: 11176
Wohnort: München
|
Clemens-XS schrieb: Ferner fokussieren wir hier jetzt zu sehr auf Nextcloud. Nextcloud ist ja nur EINE Baustelle. Bisher läuft bei mir KeePassXC nur deshalb noch reibungsfrei, weil ich mit der alten Version arbeite, also noch nicht als Snap. Angesichts der bis jetzt schon ersichtlichen Probleme habe ich mich dafür entschieden, KeePassXC-Snap noch nicht zu verwenden.
Da gäbe es ja laut https://keepassxc.org/download/#linux zwei Alternativen: ein AppImage und ein offizielles PPA des Herstellers. Oder nehmen wir andere Programme, die z.B. die Scanner-Schnittstelle benutzen können, wie LibreOffice, GIMP usw.
Ich verstehe Hang zu neuen Programmversionen nicht, wenn man eine LTS-Version einsetzt (auch wenn Xubuntu da eine merkwürdige Wahl ist, denn das wird nur drei Jahre unterstützt, das "normale" Ubuntu 18.04 bekommt volle fünf Jahre) - LTS-Versionen sind genau dafür gedacht langweilig und Feature-stabil zu sein und dir neue Versionen mit veränderter Funktionalität vom Hals zu halten, damit man über mehrere Jahre arbeiten kann ohne sich ständig um Anpassungen an Änderungen zu kümmern - bei den aktiv gepflegten Kernpaketen werden praktisch ausschließlich sicherheitsrelevante Patches eingepflegt, wie man am Changelog von LibreOffice gut sehen kann: https://changelogs.ubuntu.com/changelogs/pool/main/libr/libreoffice/libreoffice_6.0.7-0ubuntu0.18.04.8/changelog). Wenn du dich daran störst, dass Pakete aus universe bei Ubuntu tendenziell weniger gut gepflegt werden (auch hier: das passiert mit Ansage: Paketquellen (Abschnitt „universe“)), bist du mit Debian vermutlich etwas besser beraten. Und wenn du neuen Versionen nicht ständig hinterherlaufen willst, nimm eine Distribution mit einem Rolling Release Modell - wenn du nicht experimentierfreudig genug für Arch Linux bist, wäre OpenSuse Tumbleweed eventuell eine gangbare Möglichkeit.
|
tomtomtom
Supporter
Anmeldungsdatum: 22. August 2008
Beiträge: 53484
Wohnort: Berlin
|
seahawk1986 schrieb: Da gäbe es ja laut https://keepassxc.org/download/#linux zwei Alternativen: ein AppImage und ein offizielles PPA des Herstellers.
Einspruch, es gibt keine offiziellen PPAs. 😛 (Ja, ich weiß, was du meinst.)
Wenn du dich daran störst, dass Pakete aus universe bei Ubuntu tendenziell weniger gut gepflegt werden (auch hier: das passiert mit Ansage: Paketquellen (Abschnitt „universe“)), bist du mit Debian vermutlich etwas besser beraten.
Ähm, da werden die Pakete, die sich bei Ubuntu in universe befinden, entweder auch kaum oder gar nicht aktualisiert. Wenn du mit "Debian" nicht gerade testing oder unstable meinst.
|
noisefloor
Ehemaliger
Anmeldungsdatum: 6. Juni 2006
Beiträge: 28954
Wohnort: WW
|
Hallo,
Denn ich sehe, dass etwa seit Beginn 2019 Programme, die bisher in den Ubuntu-Quellen als normale Pakete vorlagen, sukzessive durch Snaps ersetzt werden. Und sobald sie ersetzt worden sind, werden die bisherigen Pakete nicht mehr aktualisiert.
Das ist falsch, siehe seahawk1986 Erklärung. Der Unterschied ist, dass es den Maintainer der snaps frei steht, eine Art Rolling Release Politik zu fahren, die es in den Paketquellen mit wenigen Ausnahmen (z.B. Firefox) grundsätzlich nicht gibt. Es ist also in den Paketquellen _nichts_ _schlechter_ geworden. Gruß, noisefloor
|