# ports-mgmt/portupgrade problem



## YuryG (Dec 29, 2016)

Since some (long) time ago I have problems with ports-mgmt/portupgrade on two very different FreeBSD 10.3-STABLE machines. So, it is not only because of accidentally corrupted database.
For some ports it can't get dependencies right. Two different machines (amd64 and i386) have problems with the same ports. For example,

```
portupgrade -c mate-settings-daemon
[Reading data from pkg(8) ... - 1601 packages found - done]
[Gathering depends for sysutils/mate-settings-daemon .................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................../usr/local/sbin/portupgrade:894:in `get_all_depends': recursive dependency (RecursiveDependencyError)
   from /usr/local/sbin/portupgrade:917:in `block in get_all_depends'
   from /usr/local/lib/ruby/2.3/set.rb:306:in `each_key'
   from /usr/local/lib/ruby/2.3/set.rb:306:in `each'
   from /usr/local/sbin/portupgrade:916:in `get_all_depends'
   from /usr/local/sbin/portupgrade:917:in `block in get_all_depends'
   from /usr/local/lib/ruby/2.3/set.rb:306:in `each_key'
   from /usr/local/lib/ruby/2.3/set.rb:306:in `each'
   from /usr/local/sbin/portupgrade:916:in `get_all_depends'
   from /usr/local/sbin/portupgrade:917:in `block in get_all_depends'
   from /usr/local/lib/ruby/2.3/set.rb:306:in `each_key'
   from /usr/local/lib/ruby/2.3/set.rb:306:in `each'
   from /usr/local/sbin/portupgrade:916:in `get_all_depends'
   from /usr/local/sbin/portupgrade:917:in `block in get_all_depends'
   from /usr/local/lib/ruby/2.3/set.rb:306:in `each_key'
   from /usr/local/lib/ruby/2.3/set.rb:306:in `each'
   from /usr/local/sbin/portupgrade:916:in `get_all_depends'
   from /usr/local/sbin/portupgrade:658:in `block (4 levels) in main'
   from /usr/local/sbin/portupgrade:621:in `each'
   from /usr/local/sbin/portupgrade:621:in `block (3 levels) in main'
   from /usr/local/sbin/portupgrade:594:in `catch'
   from /usr/local/sbin/portupgrade:594:in `block (2 levels) in main'
   from /usr/local/lib/ruby/2.3/optparse.rb:1591:in `block (2 levels) in parse_in_order'
   from /usr/local/lib/ruby/2.3/optparse.rb:1586:in `catch'
   from /usr/local/lib/ruby/2.3/optparse.rb:1586:in `block in parse_in_order'
   from /usr/local/lib/ruby/2.3/optparse.rb:1534:in `catch'
   from /usr/local/lib/ruby/2.3/optparse.rb:1534:in `parse_in_order'
   from /usr/local/lib/ruby/2.3/optparse.rb:1528:in `order!'
   from /usr/local/lib/ruby/2.3/optparse.rb:1520:in `order'
   from /usr/local/sbin/portupgrade:571:in `block in main'
   from /usr/local/lib/ruby/2.3/optparse.rb:1062:in `initialize'
   from /usr/local/sbin/portupgrade:238:in `new'
   from /usr/local/sbin/portupgrade:238:in `main'
   from /usr/local/sbin/portupgrade:2380:in `<main>'
```
Is it curable? For, there's no chance to make `portupgrade -a` after rebuilding world, for example. As far as I remember, the similar problem at first occured after ruby became version 2.


----------



## sidetone (Dec 30, 2016)

ports-mgmt/portmaster works better than portupgrade, but many on here prefer newer synth.

Maybe you need to look at or clear /var/db/ports/, where your previously chosen dependencies for ports are saved.


----------



## YuryG (Dec 30, 2016)

getopt said:


> I saw that you also need to build for i386. Think about crossbuilding i386 packages on a fast amd64 box using ports-mgmt/poudriere. It is fun having local amd64 and i386 repositories. An i386 box is typically updated within less of a minute with a single command.


Well, I tried to ask somewhere here weather is it possible and how far it is explained in details. I didn't get positive answers, or easy enough for me. May be some tutorial you can advise me, can you? For building, say www/chromium, on an old i386 (Pentium-4, specifically) is a real pain.


----------



## YuryG (Dec 30, 2016)

sidetone said:


> ports-mgmt/portmaster works better than portupgrade, but many on here prefer newer synth.
> 
> Maybe you need to look at or clear /var/db/ports/, where your previously chosen dependencies for ports are saved.


Can you help me saying what to look at? And yes, the problem is the same and with the same ports on two different not connected machines: amd64 and i386. The latter one had FreeBSD installation much later than the former one.


----------



## getopt (Dec 30, 2016)

YuryG said:


> May be some tutorial you can advise me, can you?


https://github.com/freebsd/poudriere/wiki

1. Install Poudriere on your fastest machine
2. Read the manpage!
2. Configure it
3. Get a new portstree with Poudriere command
4. create a jail for building amd64 with Poudriere command
5. create a jail for building i386 with Poudriere command
6. Create bulk-lists with the ports to be build 
7. run poudriere bulk with the lists
8. Set up a local webserver for the repositories (i.e Nginx in a jail)
9. Configure your clients to use your local repos.
10. run pkg upgrade on your clients and have fun.

Just start to try it and come back with the questions you may have in a new thread. Take your time playing with this, to get some understanding.


----------



## hukadan (Dec 30, 2016)

YuryG said:


> May be some tutorial you can advise me


You have an excellent HowTo right here : Thread 38859


----------



## sidetone (Dec 30, 2016)

/var/db/ports/ has options saved, just erase everything in the directory, to start with fresh options.  From past ports releases, it saves the options, and it keeps them even when the ports change, thus saving irrelevant options. Each file in it is saved options, that are set by `make config`, or similar. I was suggesting to check differences in past and present options, but just clear as in remove all files from that directory. You can also run a `make rmconfig-recursive` from each ports category directory in /usr/ports/, which is an example that will take too long.

Since you said, that it was by different machine architectures, it could be just that. Different programs come with different base systems (32 or 64 bit), then some ports get ignored for one architecture, because it is already in the base system. After starting fresh with new port options, if there are any differences, at least they will be more minimal.

Also, be aware that mixing ports and packages can have set different dependencies. If you do mix them, which many advise against, at least be mindful of what you are doing.

Reinstall your ports from scratch after a make world.


----------



## YuryG (Dec 31, 2016)

Well, I've found out that there's circular dependency: audio/pulseaudio (with libsoxr option) -> audio/libsoxr -> multimedia/ffmpeg (with pulseaudio option) -> audio/pulseaudio. May be that is the part of the problem?


----------



## sidetone (Dec 31, 2016)

Circular dependencies are always a problem. https://www.freebsd.org/doc/en_US.I...le-depend.html#makefile-circular-dependencies

If it's still there after you cleared out your /var/db/ports/ directory, and installed it from scratch, report it by emailing the maintainer of those three ports or to the mailing list at freebsd-ports@freebsd.org. You can also uncheck the circular dependency option on your own, if you really need to get it running.


----------

