From owner-freebsd-gnome@FreeBSD.ORG Fri Aug 9 19:09:33 2013 Return-Path: Delivered-To: gnome@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9D4A77E4 for ; Fri, 9 Aug 2013 19:09:33 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from forward7l.mail.yandex.net (forward7l.mail.yandex.net [IPv6:2a02:6b8:0:1819::7]) by mx1.freebsd.org (Postfix) with ESMTP id 492892B67 for ; Fri, 9 Aug 2013 19:09:33 +0000 (UTC) Received: from smtp14.mail.yandex.net (smtp14.mail.yandex.net [95.108.131.192]) by forward7l.mail.yandex.net (Yandex) with ESMTP id 9BE34BC0F85; Fri, 9 Aug 2013 23:09:30 +0400 (MSK) Received: from smtp14.mail.yandex.net (localhost [127.0.0.1]) by smtp14.mail.yandex.net (Yandex) with ESMTP id 36B151B6073C; Fri, 9 Aug 2013 23:09:30 +0400 (MSK) Received: from 93.91.10.81.tel.ru (93.91.10.81.tel.ru [93.91.10.81]) by smtp14.mail.yandex.net (nwsmtp/Yandex) with ESMTP id t2YmtBYCYU-9TqSBoTY; Fri, 9 Aug 2013 23:09:29 +0400 Message-ID: <52053E69.9080204@passap.ru> Date: Fri, 09 Aug 2013 23:09:29 +0400 From: Boris Samorodov Organization: =?UTF-8?B?0JfQkNCeICLQktCQ0KDQoiI=?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130806 Thunderbird/17.0.7 MIME-Version: 1.0 To: Kevin Oberman Subject: Re: UPDATING 20130731 gio-fam-backend References: <5204A921.2050103@passap.ru> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: FreeBSD GNOME Users X-BeenThere: freebsd-gnome@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: GNOME for FreeBSD -- porting and maintaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 19:09:33 -0000 09.08.2013 21:29, Kevin Oberman пишет: > On Fri, Aug 9, 2013 at 1:32 AM, Boris Samorodov wrote: > >> 09.08.2013 01:26, Kevin Oberman пишет: >> >>> I believe the note on in UPDATING 20130731 is incorrect, as least as far >> as >>> portmaster. I don't use portupgrade, >> >> So do I. >> >>> so I can't say how it behaves. This >>> also assumes that pkgng is not in use. >>> >>> If you do "portmaster -r gio-fam-backend" it will fail as it treats >> glib20 >>> as a replacement for gio-fam-backend. >> >> I doubt it. How a single command "portmaster -r gio-fam-backend" may >> even know about glib20? And IMHO glib20 cannot be used as a >> replacement. From PORTMASTER(8) about -r option: "is for >> "rebuild the specified port, and all ports that depend on it." >> > gio-fam-backend is in MOVED, so portmaster and portupgrade will see glib20 Hm. Sorry, Kevin, I do not understand you. You said: "If you do "portmaster -r gio-fam-backend" it will fail..." The command should not fail. It means "rebuild everithing which depend on gio-fam-backend and the port itself". At this time (already installed glib20) is used only as a build dependency for gio-fam-backend. I do another update while writing this e-mail. From time to time I enter the command "% pkg info -r gio-fam-backend-2.34.3 | wc -l" and the result shows lesser and lesser number. So while rebuilding those ports are removing gio-fam-backend from theirs deps. Well, when the command finishes we get a system with rebuilded gio-fam-backend but no one depends upon it and it may be safely removed. You said: "...as it treats glib20 as a replacement for gio-fam-backend." I'm not sure what you mean here. Do you mean that it will be good if...? > as a replacement for gio-fam-backend. At least portmaster does not have the > concept of a port merging into another. As a result, the "portmaster -f" > will "update" gio-fam-backend" to glib20, but will not remove the existing > glib20 port, but remove gio-fam-backend. (Ideally it would have deleted > both, but it does not understand port merges.) The actual flow is: > Build a list of ports depending on the port specified as an argument to > '-r' starting with that port > Check MOVED for the port specified as an argument to the '-r' option > If found in MOVED, replace the specified port in the update list with the > port in the MOVED file > Build any build dependencies of that port that need updates (in this case > that will usually mean gettext) > Build the port (glib20) > Delete the port being replaced (gio-fam-backend) > Install the port (which fails as glib20 s already installed) > > If glib20 was deleted before the execution of "portmaster -r", the > installation of glib20 will succeed I don't understand the problem you try to solve. Why and when the installation of glib20 will not succeed if not? (I'll repeat myself: documented commands -- portmaster -r gio-fam-backend && pkg delete gio-fam-backend) -- do not change glib20!) > Continue building all remaining ports in the list until complete > > There are a few added complexities, but this is the basic outline of the > operation. It is similar for portupgrade, but I don't know that it is > exactly the same. > >>> As a result, after building the new >>> glib port, it tries to install it without deleting the old version and >>> fails. This can be avoided by using the command "pkg_delete -f glib-2.\*" >>> before the instructions currently provided. >>> >>> Also, depending on the version of portmaster, gio-fam-backend may be >>> automatically deleted by the portmaster -r command, so the pkg_delete of >>> gio-fam-backend may fail. >>> >>> I have updated about a half dozen systems and all have required that the >>> gio-fam-backend be deleted first to allow the portmaster -r to work. >> >> So did I (about a half dozen systems) and I did what is suggested at >> UPDATING (rebuild ports with -r option and then remove gio-fam- >> backend). Modulo some problems due to new ld properties at CURRENT >> all went smooth. >> >> FYI: here is my .portmasterrc: >> ----- >> PM_SU_CMD=/usr/local/bin/sudo >> BACKUP=bopt >> MAKE_PACKAGE=gopt >> DONT_SCRUB_DISTFILES=Dopt >> SAVE_SHARED=wopt >> ----- >> > OK. I am baffled as to why it seems to work for you when uniformly failed > for me. I can only note that all of my systems were running either 8.4, 9.1 > or 9-STABLE. None used pkgng. None ran head. Some my have been running an > outdated portmaster from back in May when I last updated ports on all of my > production systems and I will admit that the 9-STABLE systems had to be > cleaned up from an inconsistent state due to trying to update > gio-fam-backend before Koop had the note in UPDATING. (Due to the attendant > changes to the files in port/Mk, it was messy and may have affected the > portmaster run, so the only systems to have the UPDATING instructions run > cleanly were running the old portmaster. I have two system types: 9-i386-STABLE and 10-amd64-CURRENT. And all of them use PKGNG. Pkg and portmaster are updated very early (the day a new version/revision hits the portstree). -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve