On Tue, Mar 04, 2003 at 12:45:19AM -0800, Kent Stewart wrote: > On Tuesday 04 March 2003 12:16 am, Stijn Hoop wrote: > > On Mon, Mar 03, 2003 at 07:42:02PM -0800, Kent Stewart wrote: > > > I learned something out of this too. Fontconfig was modified and so > > > I tried -Rup fontconfig. Portupgrade just built fontconfig. Next I > > > tried -pur fontconfig. It rebuild Xft, which had also been > > > upgraded, and just repackaged everything that used them below that. > > > Now, the kicker is that qt-3.x uses Xft.2 in the build but it was > > > not rebuilt. I had to run -pufr fontconfig for that to happend. > > > > Please send this as a problem report to the portupgrade maintainer, > > Akinori MUSHA <[EMAIL PROTECTED]>. > > I will try that tomorrow. It is too late to try it to night. I have > never used send-pr before.
If you can send mail, you can use send-pr. However, after careful reading this might not be a bug but intended behaviour. You see, the manpage says this on the -r switch (and paraphrases it for the -R switch): -r --recursive Act on all those packages depending on the given packages as well. The problem is that 'act' is not defined very well -- if you think about it, you've asked portupgrade, by using -pur, to check if fontconfig is out of date and *if so* rebuilt it, and do *the same thing* for all packages dependent on fontconfig. Now, because qt hadn't changed, portupgrade didn't rebuilt it. It probably did consider it though. You can use -v with portupgrade to check this. If you use -f, it will *unconditionally* rebuild all dependent ports. Is this a problem? Yes and no. Most of the time (and I suspect it is so with qt) the dependant ports use the shared library. This means that they will have the new functionality of the Xft port right away. There are at least two cases where this breaks: - Xft was upgraded to use a new major version. The old library is saved by portupgrade in a compatibility path, so qt and all other dependant packages will still function correctly, but it might pay to rebuild them to use the new library. Most of the time this requires source patches to the dependant ports though, because a library version bump should indicate an API breakage. - Dependant ports used the *static* library. Now they need to be rebuild after every upgrade of Xft. There's no way to avoid this except to bug the authors of the port to consider using the shared library instead. So, in retrospect, portupgrade was only doing what you told it to do. I would suggest that next time you try and let portupgrade decide what to upgrade, and check if dependant ports still work as expected. I'd estimate that in 95% of the cases, they still work. Hope this helps to clear up some of the confusion. --Stijn -- An Orb is for life, not just for Christmas.
Description: PGP signature