Date: Fri, 09 Aug 2013 23:09:29 +0400 From: Boris Samorodov <bsam@passap.ru> To: Kevin Oberman <rkoberman@gmail.com> Cc: FreeBSD GNOME Users <gnome@freebsd.org> Subject: Re: UPDATING 20130731 gio-fam-backend Message-ID: <52053E69.9080204@passap.ru> In-Reply-To: <CAN6yY1sAAaiBFAa_yxBeP-sXb58puJ4TSYeL1vC=3PS%2BQUDbWA@mail.gmail.com> References: <CAN6yY1sHRfKu%2BgUvzExaLJAuWBCRzgfsVEEepLOx6LwSkCtTgQ@mail.gmail.com> <5204A921.2050103@passap.ru> <CAN6yY1sAAaiBFAa_yxBeP-sXb58puJ4TSYeL1vC=3PS%2BQUDbWA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
09.08.2013 21:29, Kevin Oberman пишет: > On Fri, Aug 9, 2013 at 1:32 AM, Boris Samorodov <bsam@passap.ru> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?52053E69.9080204>