UPDATING 20130731 gio-fam-backend

[Kevin Oberman]

On Fri, Aug 9, 2013 at 12:09 PM, Boris Samorodov <bsam at passap.ru> wrote:

> 09.08.2013 21:29, 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
>
> 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
>

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.
-- 
R. Kevin Oberman, Network Engineer
E-mail: rkoberman at gmail.com