Hi! I would like some feedback in two ideas I have in order to solve #712264, 
"Does not depends on the binaries it masks"

Long story short, qtchooser provides symlinks to itself like:

qml -> qtchooser
qml1plugindump -> qtchooser
qmlbundle -> qtchooser

And many others, currently 38 of them.

The problem with this is that qtchooser installs them but the binary it masks 
might not be already installed. Direct dependencies would cause circular 
dependencies due to qtchooser being a dependency of libqt[4 5]core (which is 

Si I came up with two ideas, each with it's good and bad sides.

= Packaging the symlinks as separate arch=all binary packages

On the good side this is the easiest to implement. Basically we could ship:

- qt4-only symlinks in a package
- qt5-only symlinks in another package
- as many special packages we might need (for example, qtchooser-qmake and let 
qmake-qt4 and qmake-qt5 depend on it).

On the bad side it means we will create packages just for shipping a symlink.

= Using triggers

In this way we could let qmake-qt5 and qmake-qt4 trigger something that 
creates the qmake → qtchooser symlink and, once both of them are removed, 
remove the symlink.

On the good side this means not shipping more packages for just a symlink, on 
the bad side this means some logic in the middle must be present and possible 
"corner edges" that might arise.

I think the easiest one is the first, and even if it uses more disk space it's 
the easiest to maintain. However I would like to know what you think about it.

Kinds regards, Lisandro.

Lisandro Damián Nicanor Pérez Meyer

Attachment: signature.asc
Description: This is a digitally signed message part.


Reply via email to