Der große pkg (ehemals pkgng) Thread

Rakor schrieb:
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?
Zum Vergrößern anklicken....

Mit
Code: 
pkg updating | less
.

Weitere Infos unter pkg-updating(8):
PKG-UPDATING(8) FreeBSD System Manager's Manual PKG-UPDATING(8)

NAME
pkg updating -- displays UPDATING entries of software packages
Zum Vergrößern anklicken....
 
Als Workaround kannst du in deiner pkg.conf(5) auch:
Code: 
PORTSDIR:   /some/path
setzen und in /some/path
mit einem Cron-Job die UPDATING file laden. So brauchst du keinen Ports-Tree
und kannst pkg updating nutzen... Toll ist's aber nicht.
 
Es wird seitens der pkg Entwickler noch überlegt, wie man das am besten ohne lokale UPDATING Datei machen kann.
 
Mal eine Frage:

in UPDATING steht:

20131023:
AFFECTS: users of lang/perl5.12 lang/perl5.14
AUTHOR: mat@FreeBSD.org

The default perl has been switched to lang/perl5.16. If you're using binary
packages, you need to do :

# pkg set -o lang/perl5.14:lang/perl5.16
Zum Vergrößern anklicken....

Gibt es einen Grund, warum man das manuell machen muss, außer "ist in pkg noch nicht eingebaut"?
 
Weil perl5.14 und perl5.16 zwei verschiedene Pakete und nicht zwei Versionen eines Paketes sind. Den Fall gibt es - z.B. bei devel/subversion* - auch noch umgekehrt. Verschiedene Ports erzeugen dort das gleiche Paket. Mittelfristig möchte man diese Fälle auflösen.
 
Also, das mit den Compilern ist noch sehr sub-optimal gelöst. Viele Sachen bauen mit Clang nicht. Wenn ich sie dann mit GCC bauen, dann gehen sie auch nicht, weil die Requirements haben, die mit LLVM gebaut wurden und die Symbole anders sind. Wenn ich dann die Requirements auch mit GCC neubaue, dann gibts wiederum Dependencies von denen, die nicht mehr gehen.
Ich fände es ja toll, wenn es vielleicht eine alternative PACKAGESITE gebe, deren Ports alle mit GCC gebaut wurden. Aus der Differenz der beiden Paket-Cluster könnte man dann auch tolle Rückschlüsse über Probleme bei Paketen ziehen!!!
 
Also nachdem mein PKG nun motzt, dass PACKAGESITE deprecated wäre (obwohl es noch immer so in pkg.conf(5) steht) habe ich mich entschlossen das endlich mal anzupassen.
Wenn ich das alles nun richtig verstehe wollen wir pkg.conf nun gar nicht mehr haben und löschen die notfalls raus (warum auch immer). Statt dessen wird nun eine repo-datei angelegt. Soll mir soweit recht sein... Aber woher weiss denn pkg nun welches Repo es verwenden soll? Ich habe nun mein eigenes und würde gerne das offizielle zusätzlich angeben. Sprich, alles was ich selbst irgendwie konfiguriert habe nimmt er aus meinem und was dort nicht drin liegt dann halt aus dem offiziellen.
Nur finde ich keine Option um irgendwie eine Priorität anzugeben.

Danke
 
Genau. pkg.conf soll zwar weiterhin die Standardeinstellungen von pkg setzen, aber keine Repos mehr konfigurieren. Das machen nun die einzelnen Repo-Configs. Der Vorteil dabei ist, dass man sehr einfach über Scripte und ähnliches weitere Repos hinzufügen und wieder entfernen kann. Das Ganze funktioniert dann so:
- "pkg update" holt die Indexe aller bekannten Repos
- "pkg search" gibt alle in allen Repos gefunden Pakete aus
- "pkg install" installiert bei gleichen Namen in verschiedenen Repos alle Pakete, was zu Kollisionen führt
- Daher braucht man "pkg install -r $repo", was das Paket und seine Abhängigkeiten (wenn noch nicht installiert) aus dem angegebenen Repo installiert
- "pkg upgrade" aktualisiert Pakete jeweils aus dem Repo, aus dem sie installiert wurden
 
Ahhh ok, danke! Das klingt zwar noch nicht optimal aber immerhin besser als nix :)
Mir ist auch aufgefallen, dass pkg search die Pakete dann mehrmals auflistet... Toll wäre natürlich wenn (wie bei pkg upgrade) dabei stünde auf welches Repo sich nun die Zeile bezieht.

Da ich mir aber eh die komplette pkg-datenbank zerschossen habe (keine Ahnung wie). Werde ich wohl eh nochmals alles neu machen müssen...
 
Frag mich nicht warum... Aber nachdem ich die Kiste (aus einem anderen Grund) neu gestartet hatte lief pkg wieder und hat keinen Muks mehr gemacht von wegen corrupted. Sehr seltsam das.
 
Gibt es eigentlich einen Plan, wann die Ports wieder richtig funktionieren werden, sprich, dass relevante Teile bauen?

edit: und warum sind Sachen wieder kaputt, die im Sommer schonmal gingen!?
 
Zuletzt bearbeitet:
lme schrieb:
Was denn?
Zum Vergrößern anklicken....
So Programme, die Menschen nutzen, die Fotos machen zB.
graphics/darktable graphics/hugin graphics/hugin-devel

Die Version von digikam und showfoto in den Ports können keine großen PNG-Dateien öffnen... aber das hat wahrscheinlich nichts mit der Umstellung zu tun.
 
Ich habe unter FreeBSD 9.2 das Problem, dass wohl meine pkg-Datenbank hinüber ist. Ich konnte pkg-1.2.1 nicht auf 1.2.2 updaten, weil das System davon ausging, dass schon 1.2.2 installiert ist. Alles sehr seltsam. Jedenfalls habe ich pkg neugebaut und nun scheint die DB hinüber zu sein. Zum Beispiel wird ständig folgender Fehler geworfen (u.a. auch bei "portmaster -L"):

Code: 
/usr/ports/ports-mgmt/pkg # make reinstall clean
===> pkg-1.2.2 has known vulnerabilities:
error on line 5 at column 44: 'unfinished value', character: '
=> Please update your ports tree and try again.
*** [check-vulnerable] Error code 1

Stop in /usr/ports/ports-mgmt/pkg.
*** [reinstall] Error code 1

Stop in /usr/ports/ports-mgmt/pkg.

Was kann ich jetzt noch machen?
 
Yamagi schrieb:
Das schaut nach einer defekten Vulneribilities-Datenbank aus. Hilft ein "pkg audit -F"?
Zum Vergrößern anklicken....
Code: 
# pkg audit -F
error on line 5 at column 44: 'unfinished value', character: '
vuln.xml.bz2                                                                                      100%  423KB 211.7KB/s 403.3KB/s  00:02  
0 problem(s) in the installed packages found.

Das Einspielen des pkgdb-Backups hat keine Änderung gebracht.
 
Das Backup ist auch nicht notwendig, da die Datenbank selbst gar nicht zu betroffen sein scheint. In jedem Fall solltest du einen Bugreport schreiben. Dann kannst du versuchen die Vulneribility-Datenbank zu löschen:
Code: 
rm /var/db/pkg/vuln.xml
Weh tun tut das nicht, man kann sie ja neu holen. Ob es hilft, wissen wir hinterher.
 
Ein
Code: 
rm /var/db/pkg/vuln.xml
brachte keine Änderung. Bug-Report habe ich verfasst. Nur hilft mir das jetzt auch nicht weiter. So wie es aussieht, darf ich wohl alle Ports neubauen. Scheiße.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben