# How to recompile a dependency tree?



## ShelLuser (Apr 18, 2013)

Hi gang,

I'm using FreeBSD 9.1-RELEASE, running fully on ZFS and trying to fix a mistake I made while configuring/compiling pecl-imagick.

The problem is that I was convinced that I didn't require X11 (graphics) support in several ports (such as graphics/cairo, print/ghostscript9 and x11-toolkits/pango, which turned out to be a mistake since graphics/gtk-update-icon-cache depends on X11 being enabled in graphics/cairo.

So I first started to change the configuration for the ports using [cmd=]make config-recursive[/cmd], yet that didn't give me the option to change the configuration for all the port dependencies (while it should according to the documentation).

Then I resorted to [cmd=]make rmconfig-depends[/cmd] to remove the whole lot after which I could indeed reconfigure all involving ports.

The only problem is that if I try to use [cmd=]make build[/cmd] it will still go over the whole list of ports without recompiling anything, eventually ending with the error message that graphics/gtk-update-icon-cache is depending on X11 being enabled in Cairo, even though it now actually is.

So then I decided to manually fix Cairo and used [cmd=]make clean[/cmd] and [cmd=]make rmconfig[/cmd] after which I used [cmd=]make build[/cmd], this worked like a charm; I now have Cairo compiled with the X11 option enabled.

Yet this has no effect on the behaviour of graphics/gtk-update-icon-cache.

So, now losing a little focus here I ended up using [cmd=]make distclean[/cmd] in the pecl-imagick port, hoping I could simply start all over again. Yet that doesn't work either. I don't get any change in behaviour when I use [cmd=]make build[/cmd] again.

So, my question: how can I enforce a recompile?

Using [cmd=]make showconfig-recursive[/cmd] clearly shows that X11 is enabled in all dependencies, this is a definite change in configuration yet nothing recompiles.

Oh; although I'm still pretty new to FreeBSD as of yet I think that we can rule out issues with the ports collection as a whole since I've installed several other ports (apache22, mysql-server, postfix, etc.) without any problems.

Thanks in advance for any suggestions you guys may have.


----------



## jozze (Apr 18, 2013)

So the trick is to use ports-mgmt/portupgrade with the '-f' flag to force, and '-R' to recompile the dependencies. The '-C' flag forces to again set the configure flags before compiling.

`# portupgrade -C -f -R pecl-imagick`

If you prefer to use portmaster, I think it has the same flags, but check with `$ man portmaster`, just to be sure.


----------



## ShelLuser (Apr 18, 2013)

jozze said:
			
		

> So the trick is to use ports-mgmt/portupgrade with the '-f' flag to force, and '-R' to recompile the dependencies.


Ha, brilliant, you beat me just to the punch.

In the mean time (I don't stop after I post) I came across ports-mgmt/portmanager which does the exact same thing (it seems; going to read up on portupgrade later on). I've tried [cmd=]portmanager graphics/gtk-update-icon-cache -f[/cmd] and from the looks of it it*'*s now indeed compiling without complaining.

When this is done and all goes well (looking good so far) I should be able to move up the ladder again and focus (without external tools) on pecl-imagick again.

Thanks for your quick response.


----------



## jozze (Apr 18, 2013)

No problem! Happy BSD-ing :beergrin


----------



## wblock@ (Apr 18, 2013)

Don't use portmanager, it is obsolete and has been removed from ports.


----------



## ShelLuser (Apr 18, 2013)

I see you beat me to putting this to solved, I was just about to since the compile ended.



			
				wblock@ said:
			
		

> Don't use portmanager, it is obsolete and has been removed from ports.



Thanks for the warning. At the moment it still seems present (with an updated ports), but I'll be sure to keep this in mind.


----------



## wblock@ (Apr 18, 2013)

If portmanager is still in your ports tree, you do not have a current tree.  It was removed back in January.


----------



## fonz (Apr 18, 2013)

wblock@ said:
			
		

> If portmanager is still in your ports tree, you do not have a current tree.  It was removed back in January.


Just checked: ports-mgmt/portmanager is still in a ports tree that I updated only yesterday or so.


----------



## kpa (Apr 18, 2013)

It shouldn't be in the tree anymore:

http://www.freshports.org/search.php?stype=name&method=match&query=portmanager&num=10&deleted=includedeleted&orderby=category&orderbyupdown=asc&search=Search


----------



## fonz (Apr 18, 2013)

kpa said:
			
		

> It shouldn't be in the tree anymore:




```
[CMD=#]portsnap fetch update[/CMD]
[output snipped]
[CMD=#]ls /usr/ports/ports-mgmt/portmanager[/CMD]
Makefile	files		pkg-message
distinfo	pkg-descr	pkg-plist
```


----------



## wblock@ (Apr 18, 2013)

For those where /usr/ports/ports-mgmt/portmanager is still present, how did you update the ports tree?  Still using csup(1)?  Or maybe portsnap(8)?


----------



## fonz (Apr 18, 2013)

wblock@ said:
			
		

> Or maybe portsnap(8)?


Bingo.


----------



## DutchDaemon (Apr 18, 2013)

It's not in my ports tree, and you better believe it's fresh ..

Also:


```
[/usr/ports] $ grep -l portmanager INDEX-*
[/usr/ports] $
```


----------



## fonz (Apr 18, 2013)

DutchDaemon said:
			
		

> ```
> [/usr/ports] $ grep -l portmanager INDEX-*
> [/usr/ports] $
> ```


The above returns nothing for me either (and I portsnap every few days) but the directory /usr/ports/ports-mgmt/portmanager still happily exists. However:
	
	



```
[cmd=#]portmaster ports-mgmt/portmanager[/cmd]

===>>> Port directory: /usr/ports/ports-mgmt/portmanager

	===>>> This port is marked DEPRECATED
	===>>> Does not support modern ports features such as MOVED, is lacking upstream and active contributions, and does not support pkgng.  Consider using ports-mgmt/portmaster, ports-mgmt/portupgrade or pkgng.


	===>>> If you are sure you can build it, remove the
	       DEPRECATED line in the Makefile and try again.
===>>> Killing background jobs
Terminated
===>>> Exiting
```
This seems right to me. The portmanager port may have been deprecated, but it will presumably remain marked as such for a while before actually being "hard" removed from the tree.


----------



## wblock@ (Apr 19, 2013)

No, it really was removed.  portsnap(8) was only recently changed to stop using CVS, and my guess is that this is a leftover.  If you delete the portmanager directory and run portsnap(8) again, does that directory come back?


----------



## fonz (Apr 19, 2013)

wblock@ said:
			
		

> my guess is that this is a leftover. If you delete the portmanager directory and run portsnap(8) again, does that directory come back?


Tried and no it doesn't. So it does indeed seem like some sort of leftover. Just running `# portsnap fetch update` didn't actively remove /usr/ports/ports-mgmt/portmanager but after manually removing it, running portsnap doesn't recreate it either.


----------



## ShelLuser (Apr 20, 2013)

Awesome, learned quite a bit by going over this thread.

I guess I fell in somewhere in between the transition. I started my FreeBSD endeavour last Tuesday (17/4) but set up the server as it is now last Wednesday (18/4). That's also where I used portsnap to initialize the ports after the installation was finished in order to make sure that I could keep things up to date.

After re-checking I too see the deprecated warning, but unfortunately it scrolls right off the screen and it seems there isn't an easy way to be sure about this after building.

I am still a bit puzzled though because according to MOVED the change happened last January: 
	
	



```
ports-mgmt/portmanager||2013-01-06|Has expired: Does not support modern ports
```

The transition from CVS to Subversion on the other hand seems to have taken place back in 2008, so how did this port still manage to pop up in my ports collection which I only installed this week?

Or did the transition _start_ in 2008 and basically slowly (but steadily) continued until today, I guess that could explain something.


----------



## wblock@ (Apr 21, 2013)

CVS was used separately for source, ports, and docs.  Each of those switched at a different time to using Subversion.  CVS was recently officially discontinued for ports.  (Although it may still work, don't count on it.)  The portsnap(8) servers were still getting information via CVS until recently.  That would be a likely origin for this kind of problem.


----------

