ports/153300: configure error for misc/shared-mime-info-0.80

Jeremy Messenger mezz.freebsd at gmail.com
Fri Dec 24 17:17:19 UTC 2010


On Thu, Dec 23, 2010 at 6:17 PM, Ronald F. Guilmette
<rfg at tristatelogic.com> wrote:
>
> In message <AANLkTikHkS9HMVFL_JTRUtYeyixaxvxwY+doKpoi2FUv at mail.gmail.com>, you
> wrote:
>
>>On Thu, Dec 23, 2010 at 2:02 AM, Ronald F. Guilmette
>><rfg at tristatelogic.com> wrote:
>>>
>>> In message <201012201634.oBKGY97Q083871 at freefall.freebsd.org>, you wrote:
>>>
>>>>Synopsis: configure error for misc/shared-mime-info-0.80
>>>>
>>>>State-Changed-From-To: open->closed
>>>>State-Changed-By: mezz
>>>>State-Changed-When: Mon Dec 20 16:33:16 UTC 2010
>>>>State-Changed-Why:
>>>>Not missing dependency, because it already depends on perl stuff. It sounds
>>>>like you didn't follow the Perl upgrade in /usr/ports/UPDATING. You need to
>>>>reinstall all ports that depend on Perl and it will solve your issue.
>>>>
>>>>http://www.freebsd.org/cgi/query-pr.cgi?pr=153300
>>>
>><snip>
>>> Because of this seemingly pervasive problem, I think that you should
>>> give some consideration to re-opening this PR.
>>
>>No need to.
>>
>>> On the other hand, if I am wrong about any part of my analysis, then by
>>> all means, please do enlighten me as to where I have gone wrong.
>><snip>
>>
>>You have analysis it perfectly for what kind of problem you have. Only
>>a problem is that you didn't follow in the /usr/ports/UPDATING that
>>was documented about what you need to do to update your icu.
>
> Uggg.  OK.  My bad.  You're right.  I didn't see that item in there.
> (Maybe I can be forgiven for this particylar faux pas... that UPDATING
> document is now over 10,000 lines long.  Does everyone actually read
> 100% of that??)
>
> In any case, I would still like to understand why it is the case that I
> need to make this extra special effort to run "portupgrade -fr devel/icu".
> In other words, why haven't all of the port dependencies been arranged in
> such a way so that "portupgrade -a" would not have achieved the same effect?

Because of libtool or/and pkg-config issue. Same problem even in the
Linux world. Some applications don't need to be linked with some
libraries, but did anyway because of flag is in one of *.la file
or/and pkg-config. We have a hack in bsd.gnome.mk called
ltasneededhack that can help with this issue, but it requires a
careful test to make sure it's stable on each ports if it works. The
ltasneededhack will helping to not get link with library when it's not
need to be.

There is better explain in the mailing list archive somewhere that I
can't find at the moment.

> Why do I have to _force_ rebuilds of everything depending on icu?  Why
> don't all those rebuilds just occur automatically from "portupgrade -a"?
>
> My apologies if I am asking FAQs, but I obviously don't understand
> something fundamental here, and I'd like to.
>
> Should I assume that "portupgrade -a" only rebuilds those ports whose
> version numbers have changed in the ports tree, and that it ignores
> cases where the port version is unchanged and where some _other_ port
> that the given port depends on has been changed/upgraded?
>
> If so, then maybe a nice addition to portupgrade would be a new option
> that does what -a does _and_ that also forces the upgrade of any port `A'
> which depends upon any other port `B' whose version has changed (i.e.
> since port `a' was last built/installed).

Both portupgrade and portmaster have option to put your old library in
the /usr/local/lib/compat/pkg/ that way your non-rebuilt ports still
can use it until you finish with the rebuilt.

Cheers,
Mezz

> Does that seem reasonable?
>
>
> Regards,
> rfg


-- 
mezz.freebsd at gmail.com - mezz at FreeBSD.org
FreeBSD GNOME Team
http://www.FreeBSD.org/gnome/ - gnome at FreeBSD.org


More information about the freebsd-gnome mailing list