https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285503

Jason E. Hale <jh...@freebsd.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|maintainer-feedback?(kde@Fr |maintainer-feedback+
                   |eeBSD.org)                  |
                 CC|                            |jh...@freebsd.org
         Resolution|---                         |Overcome By Events
             Status|New                         |Closed
           Severity|Affects Many People         |Affects Only Me

--- Comment #1 from Jason E. Hale <jh...@freebsd.org> ---
(In reply to Peter TKATCHENKO from comment #0)
> Cannot mix incompatible Qt library (5.15.14) with this library (5.15.16)

This is only a problem if a project uses the Qt private API which it really
shouldn't do and is *highly* discouraged. Reason being, it breaks the backwards
compatibility that the public API promises. It's therefore usually unnecessary
and impractical to bump PORTREVISION on every port depending on Qt, especially
between patch releases. 

There are still a few known ports that break because they use the Qt private
API, however. These are hard to detect because it's bad and unusual practice,
so thanks for bringing this to my attention. I have a list of these and bump
them when I do Qt updates, but this one wasn't on my radar, most likely due to
a very tiny user base and that most people are using packages these days.
Considering this is an ancient abandoned project (last commit 8 years ago) from
Qt upstream, however, I can see how it would slip through the cracks any why
the rules were broken.

I'll add it to my list for next time, but honestly there aren't going to be too
many "next times" left for Qt5 or for this port. Qt5 is officially dead
upstream in May and I would estimate our local support to be about year after
that since Qt5 LGPL releases are a year behind. This is also assuming KDE keeps
rebasing their repository from which we roll our Qt5 source.

Again, thanks for bringing this up, but I'm going to close this. Qt 5.15.16
landed 4 months ago and it's kind of late at this point to bump PORTREVISIONs
based on that. The official qt5-style-plugin packages have definitely been
built against Qt 5.15.16 by now, which is what the "average user" would
typically use and what most beginners should definitely be using. Anyways, I
know what to do now and this won't be a problem again for users who don't fall
into the aforementioned categories when or if the last couple of Qt5 updates
land. Sorry for the previous confusion and inconvenience.

-- 
You are receiving this mail because:
You are the assignee for the bug.

Reply via email to