Der große pkg (ehemals pkgng) Thread

[h^2]

Und wie sieht es aus mit Konflikt-Handling? Ohne ist das IMHO nur wenig sinnvoll, weil ich dann auch wieder Sachen mit -f entfernen muss und Abhängigkeiten nicht übertragen werden.

Uns kann ich vielleicht irgendwo Ports blacklisten, die ich nicht aktualisiert habe möchte?

[Crest]

Ich sehe gerade das Problem eher bei den Versionen von Abhängigkeiten wie kann ich z.B. beeinflussen welche PostgreSQL Version installiert wird, wenn PostreSQL 9.0 und 9.1 möglich sind?

[Yamagi]

Zitat von h^2

Und wie sieht es aus mit Konflikt-Handling? Ohne ist das IMHO nur wenig sinnvoll, weil ich dann auch wieder Sachen mit -f entfernen muss und Abhängigkeiten nicht übertragen werden.

Uns kann ich vielleicht irgendwo Ports blacklisten, die ich nicht aktualisiert habe möchte?

Ob du Ports blacklisten kannst, weiß ich leider nicht. Das mit der Konfliktbehandlung ist derzeit noch so eine Sache. pkg geht davon aus, dass das genutzte Repo ins sich konsistent ist und alle lokal installierten Pakete auf dem Stand des Repos sind. Damit dürfte es keine Konflikte geben. Das Problem ist nun aber, dass mit der derzeitigen Funktion der Ports eine hundertprozentige Konsistenz nicht garantiert werden kann. Mal ein simples Beispiel: Es gibt mehrere Perl-Versionen, installiert ist Perl 5.12 und ein Paket will nun Perl 5.14. Schon explodiert es. Derzeit versucht man, bzw. hofft man, diese Probleme auf Ebene der Ports zu lösen. Das ist grundsätzlich auch erst einmal sinnvoll, schließlich ist eines der Ziele von pkg diese Frickellösungen wie "portmaster --check-depends" loszuwerden. Mittelfristig - also nach Version 1.0 - ist dann aber auch die Unterstützung für mehrere Repos parallel geplant. Und spätestens an dem Punkt muss es ein sauberes Konfliktmanagement geben.

[Yamagi]

Zitat von Crest

Ich sehe gerade das Problem eher bei den Versionen von Abhängigkeiten wie kann ich z.B. beeinflussen welche PostgreSQL Version installiert wird, wenn PostreSQL 9.0 und 9.1 möglich sind?

Indem du eine Version explizit angibst. Mal als Beispiel mit postgresql-client:

root@screw:pts/0 ~> pkg search postgresql-client 
postgresql-client-9.1.4        PostgreSQL database (client)
postgresql-client-8.3.19,1     PostgreSQL database (client)
postgresql-client-9.0.8        PostgreSQL database (client)
postgresql-client-9.2.b3       PostgreSQL database (client)
postgresql-client-8.4.12       PostgreSQL database (client)

Installiert man nun blind, versucht er alle Versionen zu installieren. Es wird aber nur die erste probierte Version registrieren, alle anderen lehnt er ab:

root@screw:pts/0 ~> pkg install postgresql-client
Updating repository catalogue
Repository catalogue is up-to-date, no need to fetch fresh copy
The following packages will be installed:

	Installing libxml2: 2.7.8_3
	Installing postgresql-client: 9.1.4
	Installing postgresql-client: 8.3.19,1
	Installing postgresql-client: 9.0.8
	Installing postgresql-client: 9.2.b3
	Installing postgresql-client: 8.4.12

The installation will require 44 MB more space

9 MB to be downloaded

Proceed with installing packages [y/N]:

Gibt man hingegen eine Version an, nimmt er die:

root@screw:pts/0 ~> pkg install postgresql-client-9.0.8                                             [14:55:04]
Updating repository catalogue
Repository catalogue is up-to-date, no need to fetch fresh copy
The following packages will be installed:

	Installing libxml2: 2.7.8_3
	Installing postgresql-client: 9.0.8

The installation will require 12 MB more space

2 MB to be downloaded

Proceed with installing packages [y/N]: ^C
root@screw:pts/0 ~> pkg install postgresql-client-8.4.12                                       
Updating repository catalogue
Repository catalogue is up-to-date, no need to fetch fresh copy
The following packages will be installed:

	Installing libxml2: 2.7.8_3
	Installing postgresql-client: 8.4.12

The installation will require 12 MB more space

2 MB to be downloaded

Proceed with installing packages [y/N]: ^C
root@screw:pts/0 ~>

Das Problem, was sich dabei stellt, ist das gleiche wie im Beitrag über diesem. Wenn du Version x.x.x installiert hast, ein anderes Paket aber als Version y.y.y als Abhängigkeit registriert hat, explodiert es.

[Crest]

Ich wollte halt PostgreSQL 9.1 statt 9.0 als default zum Glück gibt es dafür DEFAULT_PGSQL_VER=91 innerhalb der make.conf der passenden Poudriere Jail.

[Yamagi]

Achso, dann hatte ich es falsch verstanden.

[Yamagi]

Das Problem mit x11/nvidia-driver ist nun gelöst:

Solve libGL.so and libglx.so conflict situation between libGL, xorg-server and
the nvidia-driver. Install the libraries in port specific directories.
Use pkg-install and pkg-deinstall scripts to update the hardlinks to the
default locations of these files.

While here clean up some @dirrmtry lines in xorg-server plist for directories
that aren.t created by xorg-server.

Motivator:	pkgng
Inspiration:	irc, freebsd-x11@ mailinglist discussion (sorry can't find it
		anymore to give credit the people)
Reviewed by:	danfe@ (for nvidia parts), bapt@
Approved by:	danfe@ (for nvidia parts)
With hat:	x11@

Natürlich muss das pkgbeta-Repo erst noch entsprechend aktualisiert werden.

[Elwood]

Ah!! Wieder ein Showstopper weniger

In diesem Zusammenhang: Wie oft wird später das pkg bzw. pkgbeta-Repo wohl aktualisiert? Sieht ja zZt nach alle 14 - 30 Tage aus.

[Yamagi]

Ich hatte gestern Abend ein längeres Gespräch mit jemanden, der auf dem DevSubmit in Cambridge in der letzten Woche war. Da das Material auch öffentlich verfügbar ist [1], kann ich ein wenig aus dem Nähkästchen plaudern. All das sind allerdings nur Vorschläge, die sich unter Umständen noch ändern werden:

1. Pakete soll es in sogenannten Packagesets geben. Ein Packageset ist ein definierter Portstree, zum Beispiel die Ports in SVN r123456, der in Pakete durchgebaut wurde.

2. Packagesets haben eine definierte Lebensdauer, sie werden also einige Zeit unterstützt. Das schließt Sicherheitsupdates mit ein, womit noch nicht klar ist, wie diese realisiert werden. Am Ende der Unterstützung wird das jeweilige Packageset vom Server entfernt, Nutzer müssen auf ein neueres aktualisieren.

3. Es soll mindestens zwei Arten Packagesets geben. Die erste Form wird wöchentlich bereitgestellt und 3 Monate lang unterstützt. Sie ist vor allem für Nutzer gedacht, die im Moment die Ports nutzen und häufig aktualisieren möchten. Die andere Form wird monatlich bereit gestellt und entsprechend länger unterstützt werden. Wie lange ist noch zu diskutieren.

Für die Verteilung wird die fast 20 Jahre alte FreeBSD-FTP-Infrastruktur durch ein modernes CDN ersetzt, was automatisch einen optimalen Server wählt. Im Prinzip so, wie es schon bei vielen Linux-Distros der Fall ist. Das Ganze soll möglichst noch in diesem Jahr umgesetzt werden, einen klaren Termin gibt es allerdings nicht. Verzögerungen sind natürlich nicht ausgeschlossen.

pkgng selbst soll nun endlich der Standardpaketmanager in 10-CURRENT werden. Nach einigen Wochen werden die bisherigen pkg_* Tools dann aus dem Basissystem entfernt und per Port bereit gestellt werden. Man wird sie also weiterhin nutzen können, sollte es aus irgendeinem Grund nötig sein. Als nächstes steht dann pkgng 1.1 auf der Liste, eine Version die fehlende Funktionen nachliefert, Bugs behebt und Kritik einarbeitet. Mittelfristig soll es ein pkgng 2.0 geben, worin alle bis dahin gesammelten Erfahrungen abgebildet werden. Dabei ist zu beachten, dass pkgng wie das Basissystem nur innerhalb eines Zweigs vollkompatibel ist. Man kann also ein mit 1.0 erstelltes Paket auch mit 1.1 installieren, aber nicht mehr zwingend mit 2.0. Gleiches gilt vorerst für die Schnittstellen, sowohl für das Programminterface in C als auch das Shellinterface. Dies klingt allerdings schlimmer als es ist, da man pkgng eher sanft weiterentwickeln wird, wenn erst einmal eine saubere Basis geschaffen ist. Zudem wird man Kompatiblitätsbrüche vermeiden, ab 2.0 soll zumindest der Kern der Interfaces möglichst stabil bleiben.

1: http://wiki.freebsd.org/201208DevSummit

[laemodost]

Die Pluginschnittstelle finde ich übrigens sehr cool:
http://www.unix-heaven.org/writing-plugins-for-pkgng

[kmh]

Mhh und wie bekomme ich die abhängigkeiten in den Griff?

Ich habe per "pkg install" KDE4 installiert, mit kdepim-4.4.x als Abhängigkeit. Da ich 4.8.4 nutzen möchte, habe ich mit Gewalt nun die 4.4.x Pakete entfernt und die 4.8.4 installiert.

Meine DB ist nun nicht mehr konsistent, da die besagten Abhängigkeiten nicht korrekt sind. Portupgrade(-devel) meckert entsprechend.

pkgdb -F
USING PKGNG
pkgdb -F not fully supported with PKGNG yet

Wie bekomme ich nun meine Abhängigkeiten wieder in den Griff und Portupgrade zum laufen? Ich könnte wieder umsteigen auf 4.4.x aber das ist eigentlich nicht das was ich möchte ...

pkg check -d
x11/kde4 has a missing dependency: deskutils/kdepim44-runtime
x11/kde4 has a missing dependency: deskutils/kdepim44

>>> Missing package dependencies were detected.
>>> Found 2 issue(s) in total with your package database.

The following packages will be installed:

        Installing kdepim-runtime: 4.4.11.1_2
        Installing kdepim: 4.4.11.1_3

The installation will require 54 MB more space

0 B to be downloaded

>>> Try to fix the missing dependencies [y/N]:

Gibt es eine Möglichkeit manuell einzugreifen? (das Problem wurde ja schon oben von Yamagi erleutert)

[Yamagi]

Nein, gibt es derzeit leider nicht. Ich hatte das Problem letzten auf meiner Frickelkiste mit altem Xorg (im Repo) und neuem Xorg (selbstgebaut) und außer wirklich widerlichem Rumfummeln auf der Datenbank habe ich keine Lösung gefunden.

[h^2]

Ich verstehe einfach nicht, wieso man nicht wie in pkg_upgrade ein replace-on-conflicts als Option hinzufügt. Die FreeBSD ports sind nicht dafuer geeignet per friss-oder-stirb zu arbeiten, dafuer sind die Ports zu wenig modular, zu stark tunebar und die user zu große Frickler...

[Kamikaze]

Zitat von h^2

Ich verstehe einfach nicht, wieso man nicht wie in pkg_upgrade ein replace-on-conflicts als Option hinzufügt

-C

Oder redest du von pkgng's pkg upgrade?

[h^2]

Zitat von Kamikaze

-C

Oder redest du von pkgng's pkg upgrade?

Ne, ich meinte schon deins, um genau die Funktionalität ging es mir und die Frage warums dass in pkgng nicht gibt.