Der große pkg (ehemals pkgng) Thread

Weil pkg ein Binärpaketmanager. Um dein Ziel zu erreichen brauchst du einen Portmanager wie z.B. portmaster. :)
 
satriani schrieb:
Ich verstehe das nicht. Warum haben die Entwickler diese Funktion nicht berücksichtigt. Das ist doch eigentlich nicht schwer zB. bei "pkg config php5" automatisch port holen, configurieren und packet erstellen. :rolleyes:
Zum Vergrößern anklicken....
Sowas klingt einfach, waere aber unglaublich komplex. Auf Binaerebene muesste man nicht nur saemtlich Ports bauen, sondern auch in allen Kombinationen. Ich glaube nicht, das sich fuer sowas jemand so schnell finden wird, obwohl es dafuer schon elegante Loesungen gibt... fuer Einzelfaelle, wo man auf die Konfiguration nicht verzichten kann.
Man koennte natuerlich auch ueberlegen mehrere Repos anzubieten, die zB auf den Desktop zugeschnitten sind, um zB ein VLC mit verschiedenen Decodern zu kriegen.

Allerdings bin ich froh, das es wohl zumindest moeglich sein wird mit pkg 1.1 den zu den Paketen gehoerigen Portstree zu holen. So kann man dann die Programme, die man in anderen Konfigurationen will selbst passend bauen.
 
Mit pkg 1.1 kommt auch Unterstützung für mehrere Repos. Man kann also das hoffentlich bald kommende, zentrale Repo nutzen und ausgewählte Pakete aus einem eigenen Repo ziehen.
 
So, es gibt Neuigkeiten an der Paketfront:
FreeBSD schrieb:
Port managers have successfully restored some of the Project's binary package building capacity. There are some issues left still to resolve, e.g. how to publish the resulting package sets in a secure manner or how to build packages seamlessly for 8.x and 9.x systems on a recent 10.x system that the head node ("pointyhat") is running, but we are very close to finish with the preparations required for providing binary packages for the upcoming 8.4 and further releases.
Zum Vergrößern anklicken....
 
Sicherlich schwierig zu sagen. Die Beta 1 von 8.4 ist ja auch schon draußen. Ich würde daher annehmen, dass es wenige Wochen dauert.
 
An dem Tag soll auch der RC1 kommen. Aber wir wissen ja, wie leicht sich sowas verzögert. :)
 
Gibt es eigentlich eine Option um eine Installation trotz Konflikten zu erzwingen?

Mein Problem auf 9.1 mit ftp://ftp.uk.freebsd.org/pub/pkgng/:

Code: 
# pkg install sqwebmail
Updating repository catalogue
Repository catalogue is up-to-date, no need to fetch fresh copy
The following packages will be installed:

        Installing sqwebmail: 5.6.0_1

The installation will require 1 MB more space

0 B to be downloaded

Proceed with installing packages [y/N]: y
Checking integrity...pkg: WARNING: locally installed courier-imap-4.12.0,2 conflicts on /usr/local/man/man1/maildirmake.1.gz with:
        - sqwebmail-5.6.0_1

pkg: WARNING: locally installed courier-imap-4.12.0,2 conflicts on /usr/local/man/man8/deliverquota.8.gz with:
        - sqwebmail-5.6.0_1

pkg: WARNING: locally installed courier-imap-4.12.0,2 conflicts on /usr/local/sbin/sharedindexinstall with:
        - sqwebmail-5.6.0_1

pkg: WARNING: locally installed courier-imap-4.12.0,2 conflicts on /usr/local/sbin/sharedindexsplit with:
        - sqwebmail-5.6.0_1
 
Ich habe eine Lösung für mein Problem im vorigen Beitrag gefunden: Ich habe das txz Archiv ausgepackt, die problematischen Dateien aus dem Pfad und dem +MANIFEST entfernt und mit 'pkg create' ein neues Archiv erstellt. Danach habe ich das neue txz mit 'pkg add' erfolgreich installiert.

Ob die Idee jetzt gut oder schlecht war, wird sich noch zeigen.
 
Sie ist widerlich sollter allerdings funktionieren. Falls die Dateien den selben Inhalt haben sollten sie notfalls in ein eigenes Paket ausgegliedert werden. Falls sie unterschiedlichen Inhalt haben müssen halt die Pfade angepasst werden. Es würde sich anbieten die Maintainer beider Ports anzuschreiben und auf den Konflikt hinzuweisen damit solch hässliche Hacks nicht mehr nötig sind.
 
hm nun ist 8.4-RC2 draussen und es gibt immer noch keine Pakete... Auf der mailling liste hab ich auch nichts mehr gehoert.
So wie es aus schaut werd ich wohl noch eine weile die pc-bsd Pakete verwenden.
 
Hallo,

das soll absolut kein Vorwurf an irgendjemanden sein - wirklich nur eine (ganz dumme?) Frage: Was ist eigentlich das Problem mit der zentralen Erstellung von Packages. Was ist an der Built-Infrastruktur so besonders, dass das nicht (fast) autmatisch durchlaufen kann?

Für mich als Laien klingt das nach einer relativ einfachen Aufgabe: Man nimmt ein Skript wie portmaster, adaptiert es so, dass die fertigen Pakete in die richtige Verzeichnisstruktur geschoben werden und lässt die Packages dabei auch noch signieren. Dann muss man nur noch die Ports auswählen, die gebaut werden sollen (aber das passiert für die klassichen Packages ja auch).

Und wenn die technische Infrastruktur nicht da ist, dann würden sich doch bestimmt ein paar Spender oder die Foundation finden, die Kapazität in der Cloud (Amazon o.ä.) bezahlen würden.

Aber offenbar ist das gar nicht sooo einfach. Kann jemand erklären warum? Oder einen Link zu entsprechenden Seiten (ich bin sicher nicht der erste, der sowas fragt).
 
Vielleicht wäre es hilfreich, wenn man für die Ports auch Releases einführen würde, ähnlich PkgSrc oder OpenBSD.
 
jmt: Bloß nicht. Willst du 6 bis 18 Monate alte Ports als einzige unterstützte Version haben?

SolarCatcher: Denk mal ein paar Schritte weiter was für ein hochwertiges Ziel so eine Infrastruktur ist. Tausende FreeBSD Server auf einmal zu rooten in dem man z.B. das pkgng Package beim nächsten Update manipuliert wäre darüber möglich.
Dazu kommt: die Latenz muss kurz genug sein, dass Sicherheitsupdates in den Ports sich schnell genug zu allen Mirrors verteilen. Das wird auch mit sehr leistungsfähigen quad 16core Xeons und viel SSDs bei >20000 Ports nicht auf einem System möglich sein. Also muss ein verteiltes System her. Dazu kommt es muss einfach und wartbar bleiben. Damit bist du eher bei tinderbox als bei portmaster.
 
Ich bin gerade dabei ein FreeBSD 9.1 von Grund auf zu installieren und zu konfigurieren. Bei der Benutzung von ezjails musste ich in Verbindung mit dem "flavours" feststellen, dass dort pkgng benutzt / vorausgesetzt wird. Da meine Server Kiste sich noch im "Spielstadium" befindet, wird später noch einmal neu aufgesetzt, habe ich einfach mal mittels pkg2ng meine pkg Datenbank emigriert.

Prompt kam auch eine Fehlermeldung
Installing libffi-3.0.13... done
pkg: lstat(/usr/local/lib/charset.alias): No such file or directory


Wie würdet Ihr entscheiden? Gleich pkgng von Anfang an benutzen oder noch weiter warten? Warum kommt die o.g. Fehlermeldung und wie vermeide ich diese bei einer Neu-Aufsetzen von meinem System?

Danke.

LG Steffen
 
Pkgng funktioniert bei mir seit Monaten gut. Die Fehlermeldung besagt das ein Port /usr/local/lib/charset.alias behauptet installiert zu haben, aber keine solche Datei (mehr) existiert.
Leider sind die Datenbasis auf die sich pkg2ng stützen kann oft sehr dürftig, weil das alte Format so fürchterlich ist. Die einfachste Lösung wäre das betroffene Paket löschen (pkg delete -f) und neu installieren. Die eigentlichen Vorteile werden sichtbar, wenn man pkgng mit entfernten Repos nutzt. Bau dir dazu mit poudriere repos, lade sie auf nen HTTP Server hoch und werde glücklich mit pkg install -y in wenigen Sekunden statt Minuten/Stunden auf portmaster zu warten.
 
Nach Umstellung auf pkgng freue ich mich, dass ich nicht dauernd meinen porttree updaten muss (und mache es auch nicht mehr, da ich ja die neuen Pakete hab). Aber ich vermisse doch sehr den Blick nach /usr/ports/UPDATING. Gibt es denn UPDATING auch irgendwo online oder muss ich echt nur deswegen den Porttree aktuell halten?

Wie macht ihr das?
 
Spontan fällt mir in einer solchen Konstellation nur die svn/svnlite Methode ein (je nachdem, was im Basissystem gebaut wird). Über einen CHron-Job könnte man selektiv per svn svn://svn.de.freebsd.org/ports/head/UPDATING nur UPDATING erneuern. Statt svn kann auch svnlite benutzt werden (ich baue svn komplett mit dem System).
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben