Solved opencv-core and opencv-core2 conflict (worth a pr?)

S

scottro

I'm wondering if this merits filling a bug or if it's a simple, Don't mix ports and packages, stupid, problem.

Fresh install of an 11.0 workstation, where I use several typical desktop programs, such as firefox, libreoffice, and thunderbird. All these install from packages without an issue. Among other things, they use a package opencv-core.

Now, i want to install ffmpeg from ports, as I need some things not covered in its defaults. However, it uses opencv-core2, causing installation to fail because it conflicts with opencv-core. There is no port for opencv-core that I see, nor is there a pkg for opencv-core2. If one tries to just temporarily remove opencv-core, it wants to remove firefox and thunderbird, among others. In the end, I removed firefox and thunderbird, then installed ffmpeg, firefox and thunderbird from ports--as if I wanted to install them from pkg, it wanted to remove ffmpeg.

So, I'm wondering if this merits a bug report. If so, where? Against firefox and/or thunderbird (and possibly libreoffice, I'd have to doublecheck that one now). Against opencv-core? Currently, the only workaround I've found is to just install all 4 (including libreoffice) from ports, which is quite time consuming.

With Linux, it's easy to compile a local version of ffmpeg that is separate from the system, which I haven't tried doing in FreeBSD. I could make a jail, but that seems overkill.

TL;DR. WIth pkgs, opencv-core, which is necessary for firefox and some other common desktop programs, is named opencv-core. In ports, it's named opencv-core2. This will cause conflict if you install a common, or even uncommon, desktop program that uses opencv-core from ports. Does this merit a bug report?
 
Heh. The reason to use a port is due to the default options not being what I want. :) Meh, I can live with it.
 
Again, same issue that of taking a lot of time to build. However, just took a look at CURRENT, and I see it's been fixed. That is, if one does pkg install firefox or ffmepg on CURRENT, it uses opencv-core2, so the problem won't persist.

So, as I probably won't rebuild this workstation till 12.x comes out, I'm good for now. Thanks for taking the time to answer. I'm going to mark it solved, since my main question was should I file a bug, and the answer is no, it's fixed in CURRENT. :)
 
What were you trying to do is mix packages from different sets: quarterly and latest. This isn't really supported. Before building the desired port you have to make sure all dependencies are in sync with the ports tree. In ffmpeg case it'd mean upgrading opencv-core -> opencv2-core first.
 
Ah, good, that means that the next time packages are updated, one won't run into this problem.

To sum up, in case this turns up in someone's google search for something, I could also avoid the problem by editing /etc/pkg/FreeBSD.conf and changing the url from
Code: 
url: "pkg+http://pkg.FreeBSD.org/${ABI}/quarterly",
to
Code: 
url: "pkg+http://pkg.FreeBSD.org/${ABI}/latest",

Whether that would create more problems or not, I don't know, if I were doing this on a production machine (outside of my own workstation, which I'm allowed to break), I would just use ports (or poudriere).
 
scottro said:
However, just took a look at CURRENT, and I see it's been fixed. That is, if one does pkg install firefox or ffmepg on CURRENT, it uses opencv-core2, so the problem won't persist.
Click to expand...
Note that all versions (this includes -CURRENT) of FreeBSD use the exact same ports tree.

I could also avoid the problem by editing /etc/pkg/FreeBSD.conf and changing the url from
Click to expand...
Never edit that file, your changes will be lost the next time you update the machine. If you want to overrule the setting create a /usr/local/etc/pkg/repos/FreeBSD.conf:
Code: 
FreeBSD: {
 url: "pkg+http://pkg.FreeBSD.org/${ABI}/latest"
}
 
I have this very same problem, as I run KDE4 and need ffmpeg with both libpulse and x11grab enabled for screenshot/cast. Binary packages insist on being compiled with these both disabled, so I resort to building ports. What I've done to workaround this whole issue:

- Uninstalled opencv-core with # pkg delete -f then replaced it for graphics/opencv2-core. Had to build this one from ports for there were no package available at the time I looked;
- As opencv2-core is there, I changed options for multimedia/ffmpeg then built it;
- Tried # pkg set -o graphics/opencv-core:graphics/opencv2-core. Seemed to work partially but I admit not understanding what exactly this should accomplish in the first place. According to pkg(8) and pkg-set(8), whenever a package looked for opencv-core as a dependency it would instead accept opencv2-core all the same. That seems to work on local packages (so I said "partially") but # pkg upgrade somehow ignores it and complains on another basis;
- Therefore, I just reinstall the "wrong", old ffmpeg from cache every time pkg asks me to, then restore custom build through # pkg add /usr/ports/packages/All/ffmpeg-3.2.2_2,1.txz right after. Note your built package will be named and stored according your own port version and config.

My point being: you shouldn't have to uninstall anything at all. By passing "-f" flag to # pkg delete -f opencv-core it should just go and leave whatever depends on it (like Firefox) untouched. Here, pkg won't complain unless you try installing something new that depends on opencv-core. Then again, # pkg upgrade complains about ffmpeg having changed options then try to reinstall the old version.

As for this being related or not with my previously running # pkg set -o, couldn't say for sure. I just mentioned it so maybe someone else could shed some light on this matter.
 
Package dependencies are "set in stone" and cannot be changed once a package has been created. The only way to deviate from the defaults and keep using packages is by setting up your own repository.
 
You must log in or register to reply here.
Back
Top