UPDATING 20130731 gio-fam-backend

[Kevin Oberman]

On Fri, Aug 9, 2013 at 1:32 AM, Boris Samorodov <bsam at 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
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 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.

-- 
R. Kevin Oberman, Network Engineer
E-mail: rkoberman at gmail.com