PKG wants to install qtchooser, how to prevent?

The Alchemist

The Alchemist

Hey everyone,

I am trying to get Gitlab running on my server (FreeBSD 10.3).
Gitlab installs the following package: rubygem-github-linguist-5.0.11

This is causing a conflict with qtchooser, the want to install in the same directory?

After some searching on the net, it appears that qtchooser is a wrapper that replaces qt-binaries to add an option to choose between qt4 or qt5 binaries.
However, I don't have any qt4 packages installed?

Now on every pkg install or update, the qtchooser package is added to the install list.
For example, I am trying to install postgresql96-server:

Code: 
Installed packages to be REMOVED:
        php71-pgsql-7.1.4
        gitlab-9.1.9
        rubygem-github-linguist-5.0.11
        rubygem-pg-0.21.0

New packages to be INSTALLED:
        postgresql96-client: 9.6.3_2
        postgresql96-server: 9.6.3_1
        compat6x-amd64: 6.4.604000.200810_3
        qtchooser: 39

Because qtchooser is conflicting with rubygem-github-linguist, on every update/install, pkg will want to remove gitlab and rubygem-github-linguist.

I am wondering how to get rid of qtchooser, as the entire purpose is not applicable to my system...

I am still a rookie in FreeBSD, so if I am trying to do something stupid, please let me know :)
 
If I understand correctly, this is caused by a different package that depends on qtchooser, is this correct?

Is there any way to find the packages that depend on qtchooser?
 
The Alchemist said:
Is there any way to find the packages that depend on qtchooser?
Click to expand...

https://www.freshports.org/misc/qtchooser/

105 listed there.

Since you are at a standstill and can't move forward, if it was me I would try to deinstall the port qtchooser then install rubygem-github-linguist from ports.

cd /usr/ports/misc/qtchooser
make deinstall clean
cd /usr/ports/textproc/rubygem-github-linguist
make install clean

Notice I said me. With 105 programs depending on it you may break one you're not aware of. I don't see postgresql96-server as needing it though.

https://www.freshports.org/databases/postgresql96-server/
 
Trihexagonal said:
https://www.freshports.org/misc/qtchooser/

105 listed there.

Since you are at a standstill and can't move forward, if it was me I would try to deinstall the port qtchooser then install rubygem-github-linguist from ports.

cd /usr/ports/misc/qtchooser
make deinstall clean
cd /usr/ports/textproc/rubygem-github-linguist
make install clean

Notice I said me. With 105 programs depending on it you may break one you're not aware of. I don't see postgresql96-server as needing it though.

https://www.freshports.org/databases/postgresql96-server/
Click to expand...


Thank you for the information!

qtchooser does not seems to be important for me now, when I will need qt5, I can always temporarily build it after removing rubygem-github-linguist.

What I don't understand though, is if postgresql96 does not need it, why it still shows up during pkg install?
This is what I want to get rid off.
It appears in almost every pkg install...
 
The Alchemist said:
Is there any way to find the packages that depend on qtchooser?
Click to expand...

You can use this command to see the reverse-dependencies of qtchooser on your system:

pkg info -r qtchooser

There are some pkg dependency weirdness on my system too. Like some packages that depend on nothing but SDL2 happen to pull in qt4-related packages along with them.
 
So that worked for you?

The Alchemist said:
What I don't understand though, is if postgresql96 does not need it, why it still shows up during pkg install?
Click to expand...

I use ports exclusively and am not well-versed in pkg.

I have, however, seen conflicts such as this a number of times and that's how I address it.
 
Yes, building the package manually from ports worked. And honestly, I build most software from ports.

But I hate the versionised packages:
- php56 / php71
- postgresql93 / postgresql96

To manage that via ports get messy very fast.

That's why I hope I can fix pkg so that I can always start out with pkg (easy) and with issues retry it via ports.
 
The Alchemist said:
That's why I hope I can fix pkg so that I can always start out with pkg (easy) and with issues retry it via ports.
Click to expand...
Am I right to conclude that you mixed binary packages with ports more often? Because that could be the reason of this inconsistence to take place, generally speaking it's a bad idea to mix the lot.
 
ShelLuser said:
Am I right to conclude that you mixed binary packages with ports more often? Because that could be the reason of this inconsistence to take place, generally speaking it's a bad idea to mix the lot.
Click to expand...

Mixed, hmm. I'm not sure if that is what I do.

I meant that I have installed some software using packages and some software using ports.
I don't mix the dependencies from packages with ports, if that is what you mean?
 
The Alchemist said:
I meant that I have installed some software using packages and some software using ports.
Click to expand...
That's exactly what I meant, that can cause quite a few issues depending on how you installed the ports. Thing is: a binary package uses the default settings and therefor also depends on those settings to be present in each of its dependencies. So the moment you install a port manually (compile it) and change any of its options you risk running into problems.

Doesn't always have to cause problems, but it often does.
 
Thank you for confirming that. I know I read at some point, and it seemed like in the Handbook, it was a bad idea to mix ports and packages and have advised against doing it myself. Everybody else seemed to be alright with it.
 
Ah ok, I had the feeling the biggest difference between the two was ease of use and speed.

With ports, I know exactly what I installed. That is why I mostly use ports for important software.

For tryout software or high level software, I usually use packages.

After all the posts I have decided to remove Gitlab. It costs me a lot more time than expected to set up. And I did it only for a piece of software to test with.
I will test it with a dedicated (virtual) server when the time is right.

Thank you for all the advises :)
 
One question though. What does postmaster do?

Port installs right?
I can still use that with manual installed ports?

I can then stay away from pkg :)
 
I use portmaster a lot, if for no other reason than you can set all your variables at the beginning of the build process vs as programs are complied individually. It will pull all the dependencies required and what it deems necessary to be built with the program. Sometime more than you would think needed, but I trust it to do the job and it does for me.

You will on occasion see it have the same problem you encountered today and have to step in and fix it manually but it streamlines and makes things a whole lot easier IMO. I had it build every one of my programs when I rebuilt my systems with the exception of GIMP.

One of the dependencies for GIMP has a vulnerability and I had to set the flag to ignore it and built it manually.
 
The Alchemist said:
One question though. What does postmaster do?

Port installs right?
Click to expand...
I think you mean portmaster? Well, basically what it's manualpage says: manages your ports without databases or languages ;)

It's a shell script which basically takes all the hassle of manually compiling off your hands. A regular way to build a port would be to use # make config to determine the configuration, then # make install clean to build it, install it and clean things up.

So here's the first problem: it's possible that a dependency will be pulled in and set up somewhere along the way. So for example after 30 minutes of compiling (and you already doing other things) all of a sudden you could be looking at a "make config screen". You can resolve this using # make config-recursive but Portmaster basically handles the whole thing for you by ensuring that the configuration is done during the init run and then everything gets build in one run.

The Alchemist said:
I can then stay away from pkg :)
Click to expand...
No you can't ;)

pkgng is your package manager, and you're going to need it either way.

It can be a little confusing at first but...

A binary package (installed through # pkg install) is nothing more than a port which got compiled "elsewhere" with all its default settings.

But if you install a port (either using the build commands I mentioned above or using Portmaster) then you're basically doing the same thing: you're building a (binary) package which at the end of the run will get installed using pkg. Of course not the install operation but instead the add command is used there.
 
ShelLuser said:
I think you mean portmaster? Well, basically what it's manualpage says: manages your ports without databases or languages ;)

It's a shell script which basically takes all the hassle of manually compiling off your hands. A regular way to build a port would be to use # make config to determine the configuration, then # make install clean to build it, install it and clean things up.

So here's the first problem: it's possible that a dependency will be pulled in and set up somewhere along the way. So for example after 30 minutes of compiling (and you already doing other things) all of a sudden you could be looking at a "make config screen". You can resolve this using # make config-recursive but Portmaster basically handles the whole thing for you by ensuring that the configuration is done during the init run and then everything gets build in one run.


No you can't ;)

pkgng is your package manager, and you're going to need it either way.

It can be a little confusing at first but...

A binary package (installed through # pkg install) is nothing more than a port which got compiled "elsewhere" with all its default settings.

But if you install a port (either using the build commands I mentioned above or using Portmaster) then you're basically doing the same thing: you're building a (binary) package which at the end of the run will get installed using pkg. Of course not the install operation but instead the add command is used there.
Click to expand...

Thank you very much for clearing this up for me.

I now know what to use when/where.

Awesome :D
 
The Alchemist said:
...
After all the posts I have decided to remove Gitlab. It costs me a lot more time than expected to set up. And I did it only for a piece of software to test with.
I will test it with a dedicated (virtual) server when the time is right.
Click to expand...

This may sound a bit off-topic - but you can also try Gogs as a self-hosted Git service. It has a straight-forward installation procedure. You can find more information about it here:

https://gogs.io/
 
You must log in or register to reply here.
Back
Top