Conflict disaster with pkgng

[Pushrod]

I upgraded my system to use pkgng a while back, and I'm left in a state where I can't upgrade the packages, and some of them are hosed. I get numerous errors such as the one below:

pkg: WARNING: locally installed qt4-qtestlib-4.8.5 conflicts on /usr/local/include/qt4/QtTest/qtestxmlstreamer.h with:
        - qt4-testlib-4.8.5

This system has over 1100 installed packages, and I don't have the means to go through all of these issues manually. I have tried uninstalling all named packages (whatever packages are named in the warnings) in hopes that running an upgrade command will clear it out, but this approach does not work.

All I want is to reinstall everything. I don't care about warnings or upgrade steps, I just want everything replaced and made current. I checked the docs, and there doesn't seem to be an auto resolver for these types of issues.

 

[trh411]

With respect to the devel/qt4-qtestlib-4.8.5 error, see entry 20140107 in /usr/ports/UPDATING.

 

[ShelLuser]

Your problem is a bit too vague to comment on. For example; how exactly did you install those packages? Did you use the ports collection, as @trh411 thinks or are you only using binary (pre-build) software?

That makes a huge difference here.

Alas, to participate in commenting on the usage of the Ports collection, in short; make sure to have added WITH_PKGNG to /etc/make.conf on any FreeBSD version lower than 10.x if you want to use pkgng.

As to your issue of re-installing eveyrthing; I'd look into ports-mgmt/portmaster for that. From the top of my head; a simple # portmaster -af would do the job (disclaimer; I've spend most of the night hacking my system so I can't guarantee that I'm overlooking options; portmaster(8) is your friend here).

 

[kpa]

Conflicts like this will continue to crop up until the next version of the dependency solver is ready in pkg(8) and the packages can finally start using a proper REQUIRES/PROVIDES mechanism that allows the use of less strict dependencies than what is in use now. For the time being you have to avoid mixing packages and self built ports and build everything from ports if you have to do any kind of customizations to port options.

 

[Pushrod]

I managed to resolve this (for the most part) by nuking every package and starting anew. Everything seems to be ok now.

Couple observations:
Most pkg operations are glacially slow.
It seems that dependencies are needlessly "hard". mysqlbackup wants version mysql 5.5, not 5.6. I bet it works with 5.6, but the dependency definitions won't allow it to install.

Otherwise, I already don't miss using ports. No sense in compiling stuff just to get the same 1s and 0s as everyone else.

 

[SirDice]

Most pkg operations are glacially slow.

Really? I've found that it's several orders of magnitude faster than the old pkg_* tools.

It seems that dependencies are needlessly "hard". mysqlbackup wants version mysql 5.5, not 5.6. I bet it works with 5.6, but the dependency definitions won't allow it to install.

Dependencies on packages are "set in stone". You can't change them. There's work being done to make it possible to change MySQL versions for example but it's not there yet. Currently the only way to change the default versions is by building from ports. If you have several machines to maintain I can highly recommend setting up your own repository as that would allow you to build packages with the versions you want while still benefiting from package installation.

 

[kpa]

Most pkg operations are glacially slow.

Really? I've found that it's several orders of magnitude faster than the old pkg_* tools.

I'm guessing this refers to the use of the official package repositories that can be quite slow if your internet connection is on the slower side. With your own package repo that is on your own gigabit LAN the operations are lightning fast. But then again the old package tools didn't offer any searching capabilities on the remote repository so you're already getting more service with PKGNG.

 

[SirDice]

I'm guessing this refers to the use of the official package repositories that can be quite slow if your internet connection is on the slower side. With your own package repo that is on your own gigabit LAN the operations are lightning fast. But then again the old package tools didn't offer any searching capabilities on the remote repository so you're already getting more service with PKGNG.

True, but I've used both on my network. A pkg_add -r somepackage was a lot slower than pkg install somepackage with both being served from the same (local) repository machine.

 

[Pushrod]

When it comes to slow commands, I was referring to things like "pkg search", "pkg version" and others. It could be a slow connection but it seems consistently slow. I'll look into it when I have time (that is to say, I will never look into it).

 

[SirDice]

When it comes to slow commands, I was referring to things like "pkg search", "pkg version" and others.

For pkg version you can add the -I switch, that will tell it to compare versions with the INDEX file. This is a lot faster than checking each port individually. It does assume your INDEX file is up to date.