# How to deal with dependency problems when using only pkg?



## BSDBernd (Feb 15, 2014)

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:


```
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.


----------



## BSDBernd (Feb 15, 2014)

*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?


----------



## dabbill (Feb 15, 2014)

*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.


----------



## wildtollwut (Feb 16, 2014)

*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.


----------



## CirrusUK (Feb 16, 2014)

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

I registered just to say that *I* too am experiencing this issue on 
	
	



```
FreeBSD BSD 10.0-RC2 FreeBSD 10.0-RC2 #0 r259404: Sun Dec 15 08:18:20 UTC 2013
```


----------



## dabbill (Feb 17, 2014)

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

I comp*il*ed imlib2 manually from the ports tree but still get the same error when running `pkg upgrade`.


----------



## Dies_Irae (Feb 20, 2014)

*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:

```
# cd /usr/ports/graphics/imlib2
# make package
```

Create a local repository for pkg:

```
# 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:

```
# 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.


----------



## von_Gaden (Feb 20, 2014)

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

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?


----------



## kpa (Feb 21, 2014)

*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?



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.


----------



## von_Gaden (Feb 21, 2014)

*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.


----------



## SirDice (Feb 21, 2014)

*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


----------



## jb_fvwm2 (Feb 21, 2014)

*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.


----------



## BSDBernd (Feb 21, 2014)

*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.



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?


----------



## willbprog127 (Feb 24, 2014)

*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.


----------



## formateur_fou (Feb 27, 2014)

*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:

```
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`.


----------



## wblock@ (Feb 28, 2014)

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

`pkg info -ixr imlib2` should work.


----------



## dabbill (Mar 5, 2014)

*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?


----------



## wimwauters (Mar 6, 2014)

*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 app_lication_s) it seems. But then I get hundreds of warnings about conflicts. Ah well...


----------



## wildtollwut (Mar 8, 2014)

*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.


----------



## formateur_fou (Mar 9, 2014)

*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.


----------



## formateur_fou (Mar 15, 2014)

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

The package is back to the repository. Nobody answered my message on the mailing list, apart from a private email mentionning a possible license issue. There is an allusion on the Freshports site:
http://www.freshports.org/graphics/imlib2/


----------



## Chris_H (Mar 23, 2014)

*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.


*+1*
Sorry, but I _had_ to do it. Your suggestion is "spot on"!

--Chris


----------



## phoenix (Mar 24, 2014)

*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.


----------

