UPDATING 20130731 gio-fam-backend

Fri Aug 9 19:09:33 UTC 2013

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