How to deal with dependency problems when using only pkg?

BSDBernd

BSDBernd

Hello to all,

I have a question concerning pkg. Everything I installed on my system (which is a FreeBSD 10.0-RELEASE) was done by using packages. I just wanted to upgrade everything and got the following:

Code: 
bernd@BSD:~ % sudo pkg upgrade -f
Updating repository catalogue
pkg: Missing dependency matching 'graphics/imlib2'
pkg: Missing dependency matching 'graphics/imlib2'
pkg: Missing dependency matching 'graphics/imlib2'
pkg: Error while trying to install/upgrade packages, as there are unresolved dependencies:
x11-wm/awesome: graphics/imlib2
graphics/feh: graphics/imlib2, graphics/giblib
graphics/giblib: graphics/imlib2

What methods and tools are there to fix problems like that? Thank you for any answer.
 
Re: How to deal with dependency problems when using only pkg

I seems that graphics/imlib2 doesn't exist as a binary at the moment, at least if I searched that right using pkg search imlib2. This would explain the problems, am I right?
 
Re: How to deal with dependency problems when using only pkg

I started getting this same error yesterday when trying to upgrade. I have not been able to find a fix yet.
 
Re: How to deal with dependency problems when using only pkg

It seems to be a repository error. The same problem occurred on a fresh 10.0 when not all packages were yet available. I got around it by compiling the concerned ports by hand.
 
Re: How to deal with dependency problems when using only pkg

I registered just to say that I too am experiencing this issue on
Code: 
FreeBSD BSD 10.0-RC2 FreeBSD 10.0-RC2 #0 r259404: Sun Dec 15 08:18:20 UTC 2013
 
Re: How to deal with dependency problems when using only pkg

I compiled imlib2 manually from the ports tree but still get the same error when running pkg upgrade.
 
Re: How to deal with dependency problems when using only pkg

I've had the same problem, the graphics/imlib2 dependency problem prevented me from upgrading my packages. I'm still very new to the pkg world and I don't know if the fact that a single dependency problem inhibits the upgrade of all the packages is a feature or a "bug".

I worked around the problem by creating a package of graphics/imlib2 and adding it to a local repository for pkg.

Create the package of graphics/imlib2 from ports:
Code: 
# cd /usr/ports/graphics/imlib2
# make package

Create a local repository for pkg:
Code: 
# mkdir -p /my/repo/path
# cp /usr/ports/packages/All/imlib2_1.4.6,2.txz /my/repo/path
# pkg repo /my/repo/path

Create a configuration file for the new repository:
Code: 
# mkdir -p /usr/local/etc/pkg/repos
# cat << EOF >> /usr/local/etc/pkg/repos/myrepo.conf
myrepo: {
  url: "file:///my/repo/path",
  mirror_type: "none",
  signature_type: "none",
  enabled: yes
}
EOF

Now, pkg upgrade is working again and I have successfully upgraded all packages, but I'm still learning how the new package system works, so I cannot guarantee that this method is correct.
 
Re: How to deal with dependency problems when using only pkg

von_Gaden said:
I noticed another problem using ports-mgmt/pkg. I'd like to install lang/perl5.18 and then misc/mc. Well, misc/mc depends on lang/perl5.16 which, of course, conflicts with lang/perl5.18. I had two options only: to compile misc/mc or deinstall lang/perl5.18. It's strange and I found no way to fix the irrelevant dependency. Is it possible to do this?
Click to expand...

The dependency is in no way "irrelevant" because the dependencies get hard coded at package creation time. If you want to avoid this type of situations you have to compile everything yourself from ports, mixing packages and ports is still not very well supported. You can't really fix the problem with any kind of pkg(8) trickery because if a port has been compiled with Perl version 5.18 you can't suddenly tell the already compiled and linked binaries to change their dependencies to shared libraries to those from Perl version 5.16. In other words the dependencies that are recorded in the packages are just a telling you what the binary programs and libraries in the package require, those are not changeable unless there's an ABI compatibility promise between the different versions of software that is being depended on.

And to really make it clear, this is not a problem introduced by the new PKGNG system. The same problem existed with the old packages but nobody complained about it because the packages were almost useless most of the time anyway and everyone was forced to use ports.
 
Re: How to deal with dependency problems when using only pkg

Thank you very much for the quick reply. I'm not surprised since I was guessing the answer but I was not sure. You are completely right - I have been using FreeBSD since 2002 and these days I'm installing binary packages for the (almost) first time.
 
Re: How to deal with dependency problems when using only pkg

If you want to change the defaults (like Perl 5.18 instead of Perl 5.16) I highly recommend setting up your own repository with ports-mgmt/poudriere. Sure building takes time but you can do so without touching any of your currently running systems. Just start the build before going to bed and in the morning you'll have a freshly compiled repository with all the options you want. Build once, install many :e
 
Re: How to deal with dependency problems when using only pkg

I still think pkg should/could be flowcharted (not wiki'd) so that each instance (a Poudriere, a redports, a simple server, a router, a desktop, a complex server, a server farm, a NAS, a low-powered board, a no-ports install, a multi-site district office, a central location for mobile locations, a jail, a set of jails, etc.) can look up their next TODO for here -to- there upgrade/fix procedures regarding packages, ports, etc. and procedures in case of failure (mini branches within the flowchart to check details). That should even lessen the threads necc. necessary on this forum and to the freebsd-questions list, the freebsd-ports list, etc. The only difficulty I see is for its official or semi-official implementation so that procedures are in place to update and republish it in a timely manner, maybe even in pace with /usr/ports/UPDATING; /usr/src/UPDATING.
 
Re: How to deal with dependency problems when using only pkg

Dies_Irae said:
I worked around the problem by creating a package of graphics/imlib2 and adding it to a local repository for pkg.
Click to expand...

This is a nice solution. Although I am an absolute beginner in FreeBSD, I don't see what is wrong in creating ones own binary repository. If there is a newer version of a program in your own repository in another repository, i guess it should be no problem for pkg to update the software from that repository. But I do know nothing about how pkg works, so I could be completely wrong. Could an expert comment on the above solution?
 
Re: How to deal with dependency problems when using only pkg

In a case such as this, should this be submitted to the issue tracker, or should the maintainer of the port/package be contacted?

Thanks.
 
Re: How to deal with dependency problems when using only pkg

The reason of the lack of the imlib2 package is here: http://docs.freebsd.org/cgi/getmsg....ebsd-pkg-fallout/20140216.freebsd-pkg-fallout and more precisely in this part:
Code: 
fetch: http://downloads.sourceforge.net/project/enlightenment/imlib2-src/1.4.6/imlib2_loaders-1.4.6.tar.bz2: Operation timed out
This file seems available, so I guess this package should build correctly next time the repository gets updated. Here are all the affected packages: http://www.freebsd.org/cgi/ports.cgi?query=imlib2&stype=requires. And you can find the ones you use that need this library with this: % pkg query %rn imlib2.
 
Re: How to deal with dependency problems when using only pkg

Any time frame when the repositories are going to get updated to fix this error?
 
Re: How to deal with dependency problems when using only pkg

OK, none of the above worked for me on FreeBSD9.2, but I figured out that the troublemaking packages were all dependencies for zim.

So I removed the packages & libs and libraries using:
pkg delete zim
pkg delete scrot
pkg delete giblib

Then I can start pkg upgrade. It has nothing to do with imlib2 itself (it's a dependency for a long list of applications) it seems. But then I get hundreds of warnings about conflicts. Ah well...
 
Re: How to deal with dependency problems when using only pkg

I'm still having this problem with graphics/giblib and graphics/imlib2. giblib is still missing from the official repositories. There seems to be no option to pkg install that allows to ignore dependencies. Although this seems a sensible decision, it would help in this instance.
 
Re: How to deal with dependency problems when using only pkg

I sent an email to the freebsd-pkg mailing list, with a copy to the port's maintainer.
 
Re: How to deal with dependency problems when using only pkg

jb_fvwm2 said:
I still think pkg should/could be flowcharted (not wiki'd) so that each instance (a Poudriere, a redports, a simple server, a router, a desktop, a complex server, a server farm, a NAS, a low-powered board, a no-ports install, a multi-site district office, a central location for mobile locations, a jail, a set of jails, etc.) can look up their next TODO for here -to- there upgrade/fix procedures regarding packages, ports, etc. and procedures in case of failure (mini branches within the flowchart to check details). That should even lessen the threads necc. necessary on this forum and to the freebsd-questions list, the freebsd-ports list, etc. The only difficulty I see is for its official or semi-official implementation so that procedures are in place to update and republish it in a timely manner, maybe even in pace with /usr/ports/UPDATING; /usr/src/UPDATING.
Click to expand...
+1
Sorry, but I had to do it. Your suggestion is "spot on"!

--Chris
 
Re: How to deal with dependency problems when using only pkg

You mean like the new solver code that's in pkg 1.3? ;)

Basically, 1.3 should be fire-n-forget in that it will take care of MOVED and UPDATING issues automatically, and figure out exactly which versions of which packages need to be installed to get a working system after the install completes.

Bapt posted a notice about it to the -ports mailing list recently. 1.3 is available for testing now, and should be officially released in a couple of weeks.
 
You must log in or register to reply here.
Back
Top