On Mon, 3 Apr 2006, [EMAIL PROTECTED] wrote:

I recently noticed if I update a package from ports, the package manager looses the dependency data for the package. eg: updating old version of gettext

# pkg_info -R gett*
Information for gettext-0.14.5_1:
Required by:
libgpg-error-1.1
libgcrypt-1.2.2
gnutls-1.2.9
p5-gettext-1.03
gmake-3.80_2

[[[ update from ports - make ; make deinstall ; make reinstall ]]]

# pkg_info -R gett*
Information for gettext-0.14.5_2:

Is my procedure incorrect, or is this normal behavior?

 -Thanks,  Wayne

This is normal. It's what makes upgrading those ports that are required by lots of other ports so difficult.
Dependency information is version-specific.

If you run "pkg_info -r libgpg-error-1.1" you'll find that it still depends on gettext-0.14.5_1 until you rebuild libgpg-error.

Last weekend I wrote some scripts to help me deal with stale dependencies like this. My code is such an ugly perl hack that I'm ashamed to post it, and my algorithm isn't really airtight, but I'll give you the algorithm I'm using. The script just uses pkg_info, pkg_version, and grep.

1) I build a dependency hash by parsing the output of "pkg_info -ra". The keys to the hash are the names of the installed ports with the versions stripped off. The right-hand-side of the hash are the lists of dependencies with the version numbers stripped off.

2) I build what I call a "full" dependency hash from the dependency hash I built in step 1. I do this by recursively getting the dependencies for every dependency in the hash from step 1. The result is a hash just like the one from step one, only with the list of dependencies expanded to show all of the dependencies' dependencies, etc. all the way down the the ports that don't require anything. As I'm building this, I also count how many levels down I have to recurse to build each entry and remember this number for each port. I call this number the "degree" for the port. To avoid rebuilding the same ports over and over again, ports with high degrees should be built after ports with low degrees.

3) I get a list of everything I want to upgrade by parsing the output of "pkg_version -qL "="". That shows me which of my installed ports are not the same version as the port in the ports tree. Usually I'll want to upgrade those ports.

4) I add to that list all of the ports that have outdated dependencies. I get that list by parsing "pkg_info -ra" for each port and checking "pkg_info -e " for each dependency to see if it exists. If it doesn't exist, then I assume I need to upgrade the requiring port. Many times the only thing I gain by doing this is an update to the dependency information in the ports database, but sometimes (like with the recent libiconv upgrade) it's truly necessary. I don't know of any way to programmatically gauge the importance of an upgrade - all I can tell is whether the version of the port listed as a dependency still exists.

5) I take the list of ports that I built in step 3 and 4, look them up in the "degrees" hash I built at the end of step 2, sort the output by the degree I determined in step 2 and then print the list.

Then I use that list to tell me which ports that I should consider rebuilding and in what order.

I used this script to help me upgrade all the ports on a system that hadn't been upgraded in about six months. It worked pretty well. It's not always perfect, though. Dependencies can change dramatically between versions sometimes, and sometimes a port will depend on a port that doesn't exist in the database (like "linux_base") but this approach is far far better than me trying to do a big upgrade of several ports by hand when I can't immediately see the dependencies. It also gives me the freedom/power to choose to build the ports I want to build, and to build them with the options I want to use.
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to