From owner-freebsd-gnome@FreeBSD.ORG Sat Aug 10 01:19:10 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 362BA42B for ; Sat, 10 Aug 2013 01:19:10 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0D2072EEC for ; Sat, 10 Aug 2013 01:19:10 +0000 (UTC) Received: by mail-pa0-f43.google.com with SMTP id hz10so5509401pad.2 for ; Fri, 09 Aug 2013 18:19:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=LRJsyn0Gafa9mwlBowg9hS6pIP0OQsiqxH64/5+G1zw=; b=aCkoVOqjaTg7WABILNyAs7NEeFXtmOVrW11rEegREbt0g0gEfBrDlQOHCeSVJQhzI/ uVC2GZQ5+exwcEs0I/GowfdbYZ1RVU8LJk5gky7AoHoO3qyXWLon4QepLrdgZU6AJIuP KqSnbX5UKNc2A+6A5gIpNRqL0dr6OIKh7Wwb1K3XSIMGPybTn/qlcFxiZbRQ+ckRdPD6 WrLzFSkFeiYXjFckWeT2yM3pRD3GVIhYbnJFC5uUD1EqnggIbNUyhZvpx95JabbB6PyU EkzqSN+ZBOXE6tmL+Lt+QE+zi1tIPZ2iaCTKcUBqcHomeLVLntF/5pBStxNWGUvUsv39 rj0g== MIME-Version: 1.0 X-Received: by 10.68.179.36 with SMTP id dd4mr14283644pbc.64.1376097549727; Fri, 09 Aug 2013 18:19:09 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.67.14.66 with HTTP; Fri, 9 Aug 2013 18:19:09 -0700 (PDT) In-Reply-To: <52053E69.9080204@passap.ru> References: <5204A921.2050103@passap.ru> <52053E69.9080204@passap.ru> Date: Fri, 9 Aug 2013 18:19:09 -0700 X-Google-Sender-Auth: rlEUbF8rQmWxWvQJ-ccjg8ARx_o Message-ID: Subject: Re: UPDATING 20130731 gio-fam-backend From: Kevin Oberman To: Boris Samorodov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 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: Sat, 10 Aug 2013 01:19:10 -0000 On Fri, Aug 9, 2013 at 12:09 PM, Boris Samorodov wrote: > 09.08.2013 21:29, Kevin Oberman =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > On Fri, Aug 9, 2013 at 1:32 AM, Boris Samorodov wrote: > > > >> 09.08.2013 01:26, Kevin Oberman =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > >> > >>> 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 t= he > > port in the MOVED file > > Build any build dependencies of that port that need updates (in this ca= se > > 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 th= e > > 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 an= d > >>> 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=3D/usr/local/bin/sudo > >> BACKUP=3Dbopt > >> MAKE_PACKAGE=3Dgopt > >> DONT_SCRUB_DISTFILES=3DDopt > >> SAVE_SHARED=3Dwopt > >> ----- > >> > > OK. I am baffled as to why it seems to work for you when uniformly fail= ed > > 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 o= f > 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 r= un > > 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 > Boris, I have done some additional testing and I now can say that when I update portmaster before starting to deal with gio-fam-backend, everything works as advertised. So it looks like sometime between May and now portmaster and now does the right thing. I don't kinow exactly when portmaster was changed other than that it was in the past 2.5 months. --=20 R. Kevin Oberman, Network Engineer E-mail: rkoberman@gmail.com