Xorg 7.2 Upgrade

Ich denke der portupgrade -a updated dann auch xorg.
Was ich mich frage ist, wie erkannt wird, ob ein Port, dessen Version nicht geändert hat, aktualisiert werden muss oder nicht...

Edit: zu langsam...
 
Dinh schrieb:
Ich denke der portupgrade -a updated dann auch xorg.
Was ich mich frage ist, wie erkannt wird, ob ein Port, dessen Version nicht geändert hat, aktualisiert werden muss oder nicht...

Edit: zu langsam...
Zum Vergrößern anklicken....

:)

Bei allen relevanten Ports wurde die Portrevisionsnummer um eins hochgesetzt (sofern nicht ohnehin Änderungen erforderlich waren). So wird alles Notwendige aktualisiert.

@heesen:

Offenbar ist der portupgrade bei dir nicht Fehlerfrei durchgelaufen. Nochmal starten bzw. vor/nachher in die mit script geloggten Meldungen gucken, und Fehler ggf. zu Fuss beseitigen.

Gruss
 
Zuletzt bearbeitet:
Ich musste eben die Erfahrung machen, das ein Abbruch von Portupgrade (hier wegen Ruby-Fehler gestorben) nachdem X.org selbst komplett aktualisiert wurde, viele andere Programme aber noch nicht zu ziemlichen Problem führt. Ein Neustart des Programms sorgt dafür (trotz gesetzter Variable), das viele Ports ihre X11-Libs in /usr/X11R6 suchen. Das ist natürlich Murks. Ich habe nun mergebase.sh ausgeführt und danach portupgrade wieder gestartet. Es läuft weiter, also wollen wir hoffen, dass es klappt...
 
Das dauert ja ewig!
Bin mit meinem 1ghz p3 seit ca. 12h am Kompilieren und es fehlen noch ~100 Ports...
Hoffentlich läufts danach wenigstens. :)
 
Elwood schrieb:
:)

@heesen:

Offenbar ist der portupgrade bei dir nicht Fehlerfrei durchgelaufen. Nochmal starten bzw. vor/nachher in die mit script geloggten Meldungen gucken, und Fehler ggf. zu Fuss beseitigen.

Gruss
Zum Vergrößern anklicken....

bei mir ist der Portstree nach wie vor bei xorg-clients auf 6.x. Wenn ich in das Verzeichnis xorg-clients wechsle und dort make aufrufe wird xorg-clients in der Version 6.x neu erstellt.

Ich meine in dem Thread gelesen zu haben, dass es eine Obergrenze für die Aktualisierungen gibt. Bei mir gab es beim portsnap 6.120 Änderungen. Vermutlich wird beim nächsten fetch auch xorg-clients aktualisiert.
 
Da wird mir mal wieder klar, warum ich portupgrade nicht mag!
Bei vielen kleinen Packeten (und von denen hab ich reichlich) dauern die ganzen unnötigen make cleans, deinstalling, und Registerin installation for [...] beinahe länger, als das eigentliche Kompilieren... :grumble:

Anmerkung: ich will hier keinem glücklichen Portupgrade-User zu nahe treten. :)
 
Yamagi schrieb:
Ich musste eben die Erfahrung machen, das ein Abbruch von Portupgrade (hier wegen Ruby-Fehler gestorben) nachdem X.org selbst komplett aktualisiert wurde, viele andere Programme aber noch nicht zu ziemlichen Problem führt. Ein Neustart des Programms sorgt dafür (trotz gesetzter Variable), das viele Ports ihre X11-Libs in /usr/X11R6 suchen. Das ist natürlich Murks. Ich habe nun mergebase.sh ausgeführt und danach portupgrade wieder gestartet. Es läuft weiter, also wollen wir hoffen, dass es klappt...
Zum Vergrößern anklicken....

Lass mich raten: Du bist auf CURRENT unterwegs?
 
Dinh schrieb:
Da wird mir mal wieder klar, warum ich portupgrade nicht mag!
Bei vielen kleinen Packeten (und von denen hab ich reichlich) dauern die ganzen unnötigen make cleans, deinstalling, und Registerin installation for [...] beinahe länger, als das eigentliche Kompilieren... :grumble:

Anmerkung: ich will hier keinem glücklichen Portupgrade-User zu nahe treten. :)
Zum Vergrößern anklicken....
Wer die Manpage liest ist glücklicher: -wW

Für Registering Installation gibt es einen Patch auf der Mailingliste, der sollte bald auch Einzug in Current finden.

Code: 
--- /usr/src/usr.sbin/pkg_install/lib/deps.c	Wed Dec  6 20:14:13 2006
+++ usr.sbin/pkg_install/lib/deps.c	Sat May 12 23:53:36 2007
@@ -26,98 +26,144 @@
 #include <err.h>
 #include <stdio.h>
 
+void list_deps(const char *pkgname, char **pkgs, char *listed, 
+               char *check_loop, char **newpkgs, int *nrnewpkgs,
+               int *err_cnt);
+
 /*
  * Sort given NULL-terminated list of installed packages (pkgs) in
  * such a way that if package A depends on package B then after
  * sorting A will be listed before B no matter how they were
  * originally positioned in the list.
+ *
+ * Works by performing a recursive depth-first search on the 
+ * required-by lists.
  */
+
 int
 sortdeps(char **pkgs)
 {
-    char *tmp;
-    int i, j, loop_cnt;
-    int err_cnt = 0;
+    int i, err_cnt=0;
+    int nrpkgs, nrnewpkgs;
+    char *listed, *check_loop, **newpkgs;
+    char *cp;
 
     if (pkgs[0] == NULL || pkgs[1] == NULL)
 	return (0);
 
-    for (i = 0; pkgs[i + 1]; i++) {
-	/*
-	 * Check to see if any other package in pkgs[i+1:] depends
-	 * on pkgs[i] and swap those two packages if so.
-	 */
-	loop_cnt = 0;
-	for (j = i + 1; pkgs[j]; j++) {
-	    if (chkifdepends(pkgs[j], pkgs[i]) == 1) {
-		/*
-		 * Try to avoid deadlock if package A depends on B which in
-		 * turn depends on C and C due to an error depends on A.
-		 * Use ugly but simple method, becase it Should Never
-		 * Happen[tm] in the real life anyway.
-		 */
-		if (loop_cnt > 4096) {
-		    warnx("dependency loop detected for package %s", pkgs[j]);
-		    err_cnt++;
-		    break;
-		}
-		loop_cnt++;
-		tmp = pkgs[i];
-		pkgs[i] = pkgs[j];
-		pkgs[j] = tmp;
-		/*
-		 * Another iteration requred to check if new pkgs[i]
-		 * itself has any packages that depend on it
-		 */
-		j = i + 1;
-	    }
-	}
+    nrpkgs = 0;
+    while (pkgs[nrpkgs]) nrpkgs++;
+    listed = alloca(nrpkgs);
+    if (listed == NULL) {
+	warnx("%s(): alloca() failed", __func__);
+	return 1;
+    }
+    bzero(listed,nrpkgs);
+    check_loop = alloca(nrpkgs);
+    if (check_loop == NULL) {
+	warnx("%s(): alloca() failed", __func__);
+	return 1;
+    }
+    bzero(check_loop,nrpkgs);
+    newpkgs = alloca(nrpkgs*sizeof(char*));
+    if (newpkgs == NULL) {
+	warnx("%s(): alloca() failed", __func__);
+	return 1;
+    }
+    nrnewpkgs = 0;
+
+    for (i = 0; pkgs[i]; i++) if (!listed[i]) {
+	check_loop[i] = 1;
+	cp = strchr(pkgs[i], ':');
+	if (cp != NULL)
+	    *cp = '\0';
+	list_deps(pkgs[i],pkgs,listed,check_loop,newpkgs,&nrnewpkgs,&err_cnt);
+	if (cp != NULL)
+	    *cp = ':';
+	listed[i] = 1;
+	newpkgs[nrnewpkgs] = pkgs[i];
+	nrnewpkgs++;
+    }
+
+    if (nrnewpkgs != nrpkgs) {
+	fprintf(stderr,"This shouldn't happen, and indicates a huge error in the code.\n");
+	exit(1);
     }
+    for (i = 0; i < nrnewpkgs; i++) pkgs[i] = newpkgs[i];
+
     return err_cnt;
 }
 
 /*
- * Check to see if pkgname1 depends on pkgname2.
- * Returns 1 if depends, 0 if not, and -1 if error occured.
- */ 
-int
-chkifdepends(const char *pkgname1, const char *pkgname2)
-{
-    char *cp1, *cp2;
-    int errcode;
+ * This recursive function lists the dependencies (that is, the 
+ * "required-by"s) for pkgname, putting them into newpkgs.
+ */
+
+void list_deps(const char *pkgname, char **pkgs, char *listed, 
+               char *check_loop, char **newpkgs, int *nrnewpkgs,
+               int *err_cnt) {
+    char **rb, **rbtmp;
+    char *cp;
+    int errcode, i, j;
     struct reqr_by_entry *rb_entry;
     struct reqr_by_head *rb_list;
 
-    cp2 = strchr(pkgname2, ':');
-    if (cp2 != NULL)
-	*cp2 = '\0';
-    cp1 = strchr(pkgname1, ':');
-    if (cp1 != NULL)
-	*cp1 = '\0';
-
-    errcode = 0;
-    /* Check that pkgname2 is actually installed */
-    if (isinstalledpkg(pkgname2) <= 0)
-	goto exit;
+    if (isinstalledpkg(pkgname) <= 0)
+	return;
 
-    errcode = requiredby(pkgname2, &rb_list, FALSE, TRUE);
+    errcode = requiredby(pkgname, &rb_list, FALSE, TRUE);
     if (errcode < 0)
-	goto exit;
-
-    errcode = 0;
+	return;
+    /*
+     * We put rb_list into an argv style NULL terminated list,
+     * because requiredby uses some static storage, and list_deps
+     * is a recursive function.
+     */
+
+    rbtmp = rb = alloca((errcode + 1) * sizeof(*rb));
+    if (rb == NULL) {
+	warnx("%s(): alloca() failed", __func__);
+	(*err_cnt)++;
+	return;
+    }
     STAILQ_FOREACH(rb_entry, rb_list, link) {
-	if (strcmp(rb_entry->pkgname, pkgname1) == 0) {	/* match */
-	    errcode = 1;
-	    break;
+	*rbtmp = alloca(strlen(rb_entry->pkgname) + 1);
+	if (*rbtmp == NULL) {
+	    warnx("%s(): alloca() failed", __func__);
+	    (*err_cnt)++;
+	    return;
 	}
+	strcpy(*rbtmp, rb_entry->pkgname);
+	rbtmp++;
     }
+    *rbtmp = NULL;
 
-exit:
-    if (cp1 != NULL)
-	*cp1 = ':';
-    if (cp2 != NULL)
-	*cp2 = ':';
-    return errcode;
+    for (i = 0; rb[i]; i++)
+	for (j = 0; pkgs[j]; j++) if (!listed[j]) {
+	    cp = strchr(pkgs[j], ':');
+	    if (cp != NULL)
+		*cp = '\0';
+	    if (strcmp(rb[i], pkgs[j]) == 0) { /*match */
+		/*
+		 * Try to avoid deadlock if package A depends on B which in
+		 * turn depends on C and C due to an error depends on A.
+		 * It Should Never Happen[tm] in real life.
+		 */
+		if (check_loop[j]) {
+		    warnx("dependency loop detected for package %s", pkgs[j]);
+		    (*err_cnt)++;
+		}
+		else {
+		    check_loop[j] = 1;
+		    list_deps(pkgs[j],pkgs,listed,check_loop,newpkgs,nrnewpkgs,err_cnt);
+		    listed[j] = 1;
+		    newpkgs[*nrnewpkgs] = pkgs[j];
+		    (*nrnewpkgs)++;
+		}
+	    }
+	    if (cp != NULL)
+		*cp = ':';
+	}
 }
 
 /*
 
Dinh schrieb:
Da wird mir mal wieder klar, warum ich portupgrade nicht mag!
Bei vielen kleinen Packeten (und von denen hab ich reichlich) dauern die ganzen unnötigen make cleans, deinstalling, und Registerin installation for [...] beinahe länger, als das eigentliche Kompilieren... :grumble:

Anmerkung: ich will hier keinem glücklichen Portupgrade-User zu nahe treten. :)
Zum Vergrößern anklicken....

Lass erstmal ein "portsclean -C" laufen, was alle work directories im Portstree loescht. Dann kannst du portupgrade mit -w aufrufen, was das "make clean" vor dem Bau von eines Ports auslaesst.
Desweiteren koenntest du dir mal die Patches fuer bsd.port.mk und pkg_install installieren, dann laeuft das Ganze noch ein bisschen schneller.

Siehe: http://blogs.freebsdish.org/netchild/2007/05/17/speeding-up-the-package-dependency-list-creation/
 
Danke euch. :)
Ja, ist mir schon klar, dass eigentlich ich der doofe bin...
Nur doof, dass es nötig ist, mich für diese kleine Update-Orgie extra in ein neues Tool einzuarbeiten. ;)

Edit: Kleine Randfrage
Wenn der Patch für pkg_install in current einzug hält, kann es sein, dass es ein freebsd-update dafür geben wird, oder kommt das frühstens mit 6.3 bzw. 7.0?
 
Zuletzt bearbeitet:
Was grept ihr da? ;)
Code: 
pkg_version -vl "<"
bzw.
Code: 
pkg_version -vl\<

Wer portupgrade installiert hat, sollte aber gleich portversion (mit den gleichen Parametern) benutzen, das laeuft wesentlich schneller.
 
Kamikaze schrieb:
Wer die Manpage liest ist glücklicher: -wW
Zum Vergrößern anklicken....
Oh ja, Supi... dann weiss ich fürs nächste Riesenupdate bescheid!

Für Registering Installation gibt es einen Patch auf der Mailingliste, der sollte bald auch Einzug in Current finden.
Zum Vergrößern anklicken....

Was eigentlich bei mittlerweile 1400 (vormals 850) installierten Ports am längsten dauert, ist die "Modifying +CONTENTS" - Geschichte. Da du in dem Maillisten-Thread aktiv bist: Wird das dort auch Performancesteigerungen geben? Blicke bei dem Thread nicht mehr wirklich durch :)

Gruss, Elwood
 
Ja gab es auch, aber das ist alles noch zu experimentell. Der Patch den ich gepostet habe bringt die größte Verbesserung.
 
Na hoffentlich kommt das bald. :)
Hab das gefühl, je mehr Ports installiert sind, umso länger dauerts...

Kann man den Patch auch in eine normale 6.2-Installation einspielen, und wenn ja, wie?
File ersetzen; cd /usr/src/usr.sbin/pkg_install; make install clean
??
 
# cd /usr/src
# patch < /pfad/zum/patch
# cd usr.sbin/pkg_install
# make install clean
 
Eine Neuinstallation von xorg72, also ohne alte Version jemals installiert zu haben, bricht er ab und verweist mich auf die UPDATING. Das ganze erschien erstmals als ich php5-gd installieren wollte.

Das Installieren der xorg-libraries von Hand hat auch nicht funktioniert. Muss ich bei einer Neuinstallation genauso vorgehen wie beim upgraden?
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben