On Tue, Apr 17, 2007 at 08:58:42PM +0200, Michael Nottebrock wrote: > > Would bumping revision of qmake and qt be enough or were you thinking of > > something more aggressive? > > No - I'm guessing the problem is that qmake generates wrong dependencies in > Makefiles when it configures Qt with a prefix that is different from the one > of a previously installed Qt, with the dependencies being generated on files > in the destination install prefix instead of the workdir. The most obvious > workaround: Deinstall (as in make deinstall) qt33, then (and only then) > rebuild and reinstall qt33 with the new PREFIX set. An update script could > take care of this rather easily as part of a post-update cleanup routine. > > I can also try to reproduce this and, if I succeed, try to come up with some > post-configure in-place Makefile editing, if my guess turns out to be > correct, but I am still busy with changing a number of qt4 ports to avoid > conflicting with qt33 after the X11BASE-move and flz@ already told me would > very much like to remain on schedule and do the merge on the upcoming > monday - I'm simply not sure I will be able to address this problem in time. > > Another option would be doing nothing, writing up an UPDATING entry and > pointing disgruntled users to that, of course. ;)
I think having qt33 upgrade automatically (i.e. without requiring manual action) is a requirement for the xorg upgrade. We are currently also blocked on a portupgrade issue, but hopefully someone else will be able to fix qt in the next few days if you don't have the time. I would like to see a real solution instead of an upgrade script workaround (as mentioned no other ports are special-cased at this time because we have been able to find ways to avoid it). Kris
pgpuiI6RadlgJ.pgp
Description: PGP signature
_______________________________________________ kde-freebsd mailing list kde-freebsd@kde.org https://mail.kde.org/mailman/listinfo/kde-freebsd