Date: Fri, 9 Aug 2013 10:29:52 -0700 From: Kevin Oberman <rkoberman@gmail.com> To: Boris Samorodov <bsam@passap.ru> Cc: FreeBSD GNOME Users <gnome@freebsd.org> Subject: Re: UPDATING 20130731 gio-fam-backend Message-ID: <CAN6yY1sAAaiBFAa_yxBeP-sXb58puJ4TSYeL1vC=3PS%2BQUDbWA@mail.gmail.com> In-Reply-To: <5204A921.2050103@passap.ru> References: <CAN6yY1sHRfKu%2BgUvzExaLJAuWBCRzgfsVEEepLOx6LwSkCtTgQ@mail.gmail.com> <5204A921.2050103@passap.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Aug 9, 2013 at 1:32 AM, Boris Samorodov <bsam@passap.ru> 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 fa= r > 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 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 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 o= f > > gio-fam-backend may fail. > > > > I have updated about a half dozen systems and all have required that th= e > > 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 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. --=20 R. Kevin Oberman, Network Engineer E-mail: rkoberman@gmail.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAN6yY1sAAaiBFAa_yxBeP-sXb58puJ4TSYeL1vC=3PS%2BQUDbWA>