On 2024/03/23 22:15, Rafael Sadowski wrote:
> On Thu Mar 14, 2024 at 09:58:52PM +0000, Stuart Henderson via ports wrote:
> > This needs something more, the qt-headers package needs to be knocked out
> > unless one of the qt versions is built.
>
> $ env TRUSTED_PKG_PATH=/usr/ports/packages/amd64/all doas pkg_add -Dunsigned
> -u
> gpgme+gpgme-qt-1.23.2->gpgme-1.23.2p0+gpgme-qt-1.23.2p0+gpgme-qt-headers-1.23.2:
> internal conflict between gpgme-1.23.2p0 and gpgme-qt-1.23.2p0
That's a different issue, I only got as far as testing build rather than
updates (which fails with FLAVOR="no_qt no_qt6", as will be the case on
archs where Qt is disabled, or the user builds with that on purpose to
quickly update without having to install a bunch of Qt packages).
> Unfortunately, you're right. Do you have any idea how we can solve this
> puzzle?
This only affects things in kde-applications at the moment, right?
Will those be moving to qt6 as part of a single update, or will they be
done individually?
If it's a single update then the most obvious answer would be to
change gpgme-qt to providing qt6 support instead of qt5.
> (One comment below)
...
> > > +LIB_DEPENDS-qt-headers =
> > > +RUN_DEPENDS-qt-headers =
> > > +# XXX WIP: not accurate enough, should handle REVISION
> > > +LIB_DEPENDS-qt += ${MODQT5_LIB_DEPENDS} \
> > > + gpgme-=${VERSION}:${BUILD_PKGPATH},-main
> > > +RUN_DEPENDS-qt =
> > > gpgme-qt-headers-=${VERSION}:${BUILD_PKGPATH},-qt-headers
>
> That doesn't help but ...
> gpgme-=${VERSION}p${REVISION-main}:${BUILD_PKGPATH},-main
That breaks if REVISION-main is unset. You could rely on PKGSPEC-main
instead? Although, for most cases -=${VERSION} is probably good enough..
