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,
> 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):

     --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.


An Orb is for life, not just for Christmas.

Attachment: pgp00000.pgp
Description: PGP signature

Reply via email to