# pkg doesn't upgrade dependency of dependency



## darkemon (Jul 8, 2019)

Hello!

I build ports in poudriere and I have some my own ports:
abc/ics
abc/ics-squid

The port abc/ics has RUN_DEPENDENCY= ics-squid>0:abc/ics-squid
The port abc/ics-squid has RUN_DEPENDENCY= squid3>0:net/squid3

The main idea is updating abc/ics-squid and net/squid3 via *pkg upgrade abc/ics*
And all worked well. But I ran into a problem: *pkg upgrade abc/ics* doesn't update squid after changing line RUN_DEPENDENCY= squid3>0:net/squid3 to RUN_DEPENDENCY= squid>0:net/squid in port abc/ics-squid, just says:

Checking integrity... done (1 conflicting)
  - squid-4.7_1 conflicts with squid3-3.5.28_2 on /usr/local/etc/squid/cachemgr.conf.sample

After that pkg updates abc/ics, but doesn't update abc/ics-squid.

But if I run *pkg upgrade abc/ics-squid*, pkg asks about upgrading squid3 -> squid4 and upgrades it if I confirms.
So, the question is: is it a bug, a feature or undefined behavior?


----------



## SirDice (Jul 8, 2019)

Upgrade everything, not single packages; `pkg upgrade`.


----------



## darkemon (Jul 8, 2019)

SirDice said:


> Upgrade everything, not single packages; `pkg upgrade`.


I can't because after installing `aaa/ics-squid` removes some files that belong to `net/squid` and if I upgrade everything these files can be restored after upgrading `net/squid`.

For example: 
I have installed `ics-squid`  version 1.0.0 and `squid` version 3.5.28. One day released new version of `squid` (e.g. 3.6.0). I run `pkg upgrade` and see that `net/squid` has been upgraded but `aaa/ics-squid` hasn't. So I get files shipped with `net/squid`, that have been deleted by installing `aaa/ics-squid 1.0.0`.

P.S. I fixed RUN_DEPENDENCY lines in the first post


----------



## SirDice (Jul 8, 2019)

darkemon said:


> I run  pkg upgrade and see that  net/squid has been upgraded but  aaa/ics-squid hasn't.


That's entirely under your own control since you're running your own repository.


----------



## darkemon (Jul 8, 2019)

So what is the answer to the question in the first post?


----------



## Lamia (Jul 8, 2019)

Sometimes I wonder of what use is Poudriere for our Org. We installed it almost a year ago and had only used it about that time.
Here is a scenario that describes the problem:
The preferred way of installing applications is via ports. However, Chromium 62 could not be installed via ports. It kept throwing Perl error. So, we had to install chromium via 'pkg install'. Most times, we would install all the dependencies via ports until we can no more do so, then we will finish the installation via pkg install. We don't both using pkgs from our Poudriere; we rather fetch them from the FreeBSD repo when needed. So, what is it needed for?

Another scenario is that say Chromium 62 again fails to be installed via ports. So we install it with all its dependencies (e.g. Perl 5.24) via pkg. At any future time we try to install an app/pkg via ports, the system throws an error 'Perl5.24 deleted from ports' and portmaster stops. If deleted, Chromium will stop working yet it can't be built one because of one bug or the other. If we follow the above remedy (i.e. install dependencies one-by-one via ports and then finalise with pkg or use pkg once and for all), there is just no need for Poudriere.

There are many other scenarios I could create to describe the problem. By the way, Firefox-esr 60.8.0.2_1 and Chromium 70.0.3770 were successfully built on FreeBSD 12 yesterday. Hurray! I can't remember the last time either of them was successfully built on the box despite our constant update of the userbase, kernel and ports.

At the moment, I am thinking one good use of it is to try build the problematic pkgs from it. In the past, we had periodically fetched all installed libraries/dependencies/apps on our servers and then package them via Poudriere. That was taking for ever - tweaking the build (make.conf, src.conf) etc AND it was very annoying. Going by what SirDice said in the above, that would be a good practice since we can then try source our pkgs/dependencies from our repo. But again, it is annoying building all in our package management system.

I keep thinking of its use; a useful tip was reinforced. Thanks SirDice. I hope someone else too got such tip(s) from this thread.


----------



## SirDice (Jul 8, 2019)

Set up your own repository, and install _everything_ from that repository. Then you have complete control over what gets updated at what point in time. Because you control the ports tree and you decide when to run a new poudriere build. Don't want updates? Don't do a full poudriere run with an updated ports tree. Only need some additional packages? Add those packages to the build list, don't update the ports tree and only do a build run.

Most people are making it more difficult than needed.


----------



## darkemon (Jul 8, 2019)

I use packages only from my own repo and it's synchronized with official svn tree in specified period. I don't have any problems with dependencies except those described in this thread.


----------



## Lamia (Jul 8, 2019)

SirDice said:


> Only need some additional packages? Add those packages to the build list, don't update the ports tree and only do a build run.
> .


Poudriere could be active and reactive as described by you.
I would want latest ver. of pkgs of course. I regularly update my boxes. Let's just say we should run Poudriere very regularly too, and build all existing and new pkgs we want from it. And only install via pkg from it. 

One other thing that I am picking from here is that if we update the Poudriere/jail OS and ports and try build all installed ports, we may identify potential problematic ports ahead of time, when we manually update the OS/jails and installed ports.

That is worth trying out via cron jobs. Thanks.


----------

