[Bug 242905] misc/qtchooser symlinks break users tools and qt5 deps

[bugzilla-noreply at freebsd.org]

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

--- Comment #2 from grarpamp at gmail.com ---
> (1) It does not ... install symlinks

The qtchooser *package* tarball as created and shipped
from the *port* does lay down symlinks, they are not
made from the pkg script, they come from the hier...
tar -tvf qtchooser-66.txz | grep '^l' | wc -l
      47

If upstream qtchooser is creating them,
the port could comment the symlink part out.

> only creating the wrapper-bin when it is needed

Maybe meaning... not creating the wrapper-bin aka qtchooser,
but the symlink.

> messy when looking forward to having again multiple Qt versions

The symlinks target and source are not versioned,
and they just point to qtchooser. So on install
different vers can test or overwrite.

On remove, the pkg would have to check if other
versions are still needing the link. I think the
pkg database can test if a file is managed.

If not that's out, if so it's a hack.

> additional port per binary which installs the wrapper
> that would be >30 additional ports.

Messy, true.


> (2) Qt6 is on the horizon

True.


> (3) Why would you need to satisfy them?

Users other tools/apps may test for their existance (some
filename on disk), or for execution, instead of for full function.
Further, the exit qtchooser throws for a broken symlink
is the same as a bare exec of some of the apps it links to.

$ not_on_disk 2>/dev/null ; echo $?
127
$ [ -e not_on_disk ] ; echo $?
1
$ qgltf ; echo $?
qgltf: could not exec '/usr/local/lib/qt5/bin/qgltf': No such file or directory
1
$ qmake > /dev/null ; echo $?
1
$ qmake --version > /dev/null ; echo $?
0

> un-nice to have wrapper binaries in path which miss the thing being wrapped.

Generally yes, there shouldn't be broken links or
broken exec installed.
Sure the links are preparatory for other packages,
it just seems like the sub packages should be add/del
their own links themselves.

> If you don't need them, then why install them?

Because in this situation, for users tool/app to
act a bit cleaner/obvious, user either have to remove
the broken symlink[s], or install the sub pkg[s].


> (4) I would love to only provide one Qt5 package instead of splitting it in multiples

That seems a different topic.

Was referring specifically to making this meta port ...
https://svnweb.freebsd.org/ports/head/devel/qt5
... produce its own meta package whose sole purpose
upon pkg-install is for pkg to then go fetch and
install all its underlying dep requirement packages...
today's 'multiples'.
Pkg tarball would not physically contain the other pkgs
in it, only call them as deps. It would not effect the
existing splitting, no change, other than qt5 metaport
now also appears as a pkg. Xorg and lots of other
metaports run packages like this.

The links in qt5 would still be subject to the
pkg-remove problem vs qt<N> as above.



On discussion balance I don't think the issue is critical,
users will still figure it out.
Whatever works or close it, cheers :)

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