Der große pkg (ehemals pkgng) Thread

So, bapt@ hat die Version 1.0 für den 30. August angekündigt. Zudem schreibt er, dass das Problem mit x11/nvidia-driver demnächst gelöst sein sollte:
Code: 
Hi all,

Since 1.0-rc6 release, everything looks ready for a final release of 1.0, I'll
give more details on the release commit bit :) this is planned for 30th august
2012.

Current was supposed to switch to pkgng by default today, it has been delayed
until the nvidia-driver is fixed with pkgng. Thanksfully kwm@ and danfe@ has
been working on this, and the situation should be fixed pretty soon.

Please continue testing pkgng and reporting bugs, if you are new comers do not
hesitate to ask question about pkgng so that we can improve documentation:

The usual links about pkgng:
  - http://wiki.freebsd.org/pkgng
  - http://wiki.freebsd.org/PkgPrimer
  - https://github.com/pkgng/pkgng/blob/master/FAQ.md
  - http://people.freebsd.org/~bapt/pres-pkgng-bsdcan.pdf
  - http://www.youtube.com/watch?v=4Hxq7AHZ27I

regards,
Bapt
 
Ein gleich noch eine Liste von Dingen hinterher, die zur absoluten Glückseeligkeit noch fehlen:

- portmaster muss nach wie vor manuell gepatcht werden. Ich hoffe, dass der Patch bald Teil von Portmaster wird, aber offiziell ist dort nichts zu erfahren.

- Diverse Tools und Scripte können noch nicht mit pkg. Ein Beispiel ist BSDPAN, aber es finden sich sicher noch mehr. Die meisten dieser Probleme dürften sich lösen, wenn pkg in naher Zukunft in 10-CURRENT zum Standardpaketmanager wird.

- pkg kämpft teilweise noch blinden Abhängigkeiten (Abhängigkeiten, die das Paketsystem nicht sieht) und in verschiedenen, aber kompatiblen Versionen vorliegenden Ports. Das ist aber kein Problem von pkg, viel mehr liegt es in den zugrundeliegenden Ports begründet. Auch das dürfte sich nach einiger Zeit in 10-CURRENT von allein auswachsen.

- Es muss noch entschieden werden, für welche Platformen Repos angeboten werden und wie oft diese aktualisiert werden. Derzeit experimentiert man mit einem partiellen Repo für FreeBSD/ARM.
 
Auf ARMs >20000 Ports zu bauen ist halt ein klein wenig Geduld nötig. Ansonsten kann man mit poudriere seine eigenen Repos erstellen wobei poudriere ZFS benötigt und damit auf ARM für absehbare Zeit nicht nutzbar ist.
 
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?
 
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?
 
h^2 schrieb:
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?
Zum Vergrößern anklicken....
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.
 
Crest schrieb:
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?
Zum Vergrößern anklicken....

Indem du eine Version explizit angibst. Mal als Beispiel mit postgresql-client:
Code: 
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:
Code: 
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:
Code: 
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.
 
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.
 
Das Problem mit x11/nvidia-driver ist nun gelöst:
Code: 
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.
 
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.
 
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
 
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.

Code: 
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 ...

Code: 
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)
 
Zuletzt bearbeitet:
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.
 
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...
 
Folgendes Problem hab ich hier auf meiner PC-BSD 9.1 Kiste. Nachdem ich pkg2ng ausgeführt hatte, sagte er mir dass es einen Fehler beim hinzufügen von libglu, libglut und dem NVIDIA Treiber gab. Leider habe ich kein log mehr. Anscheinend konnte er diese beiden Sachen nicht in die Datenbank übernehmen. Würde der Upgrade des Ports das wieder gerade biegen?
 
Yamagi schrieb:
Nachdem pkg installierst ist - sei es über die Ports aus ports-mgmt/pkg oder per /usr/sbin/pkg - führst du "pkg2ng" aus. Damit wird die Datenbank in /var/db/pkg konvertiert. Außerdem kommt noch ein "WITH_PKGNG=yes" in die /etc/make.conf.
Zum Vergrößern anklicken....

Was genau heißt "Damit wird die Datenbank in /var/db/pkg konvertiert." Bleibt die vorhandene Installation von packages bestehen und wird nur etwas umgeschrieben, oder werden alle alten packages zunächst deinstalliert und die neuen neu installiert? Und wie lange kann das dauern bei über 700 installierten packages? Existieren nun im neuen System alle ports auch als packages, oder müssen einige Sachen wie Flashplayer immernoch als ports installiert werden?
 
Die installierten Ports/Pakete bleiben installiert. Bei pkg2ng wird lediglich aus den Daten in /var/db/pkg eine SQLite Datenbank erstellt und dann /var/db/pkg umbenannt.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben