unreliable pkg upgrades

[Guido Falsi]

On 05/22/18 23:58, Miroslav Lachman wrote:
> Am I the only one seeing occasional unreliable pkg upgrades?
[...]
> root at jahoda ~/# pkg upgrade devel/php-composer
> Updating codelab repository catalogue...
> codelab repository is up to date.
> All repositories are up to date.
> The following 1 package(s) will be affected (of 0 checked):
> 
> New packages to be INSTALLED:
>         php71-composer: 1.6.3
> 
> Number of packages to be installed: 1
> 
> The process will require 2 MiB more space.
> 380 KiB to be downloaded.
> 
> Proceed with this action? [y/N]: y
> [1/1] Fetching php71-composer-1.6.3.txz: 100%  380 KiB 389.3kB/s    00:01
> Checking integrity... done (1 conflicting)
>   - php71-composer-1.6.3 conflicts with php-composer-1.6.2 on
> /usr/local/bin/composer
> Checking integrity... done (0 conflicting)
> Conflicts with the existing packages have been found.
> One more solver iteration is needed to resolve them.
> The following 2 package(s) will be affected (of 0 checked):
> 
> Installed packages to be REMOVED:
>         php-composer-1.6.2
> 
> New packages to be INSTALLED:
>         php71-composer: 1.6.3
> 
> Number of packages to be removed: 1
> Number of packages to be installed: 1
> 
> Proceed with this action? [y/N]: y
> [1/2] Deinstalling php-composer-1.6.2...
> [1/2] Deleting files for php-composer-1.6.2: 100%
> [2/2] Installing php71-composer-1.6.3...
> [2/2] Extracting php71-composer-1.6.3: 100%

Since this is referencing a port to which I committed lately I'm felling
compelled to reply.

Adding php flavors to composer required changhing the pkgname, so pkg
considers it a different one.

I added an entry in UPDATING about this, entry 20180412, explaining you
had to take a manual step to let pkg know about the name change. If you
skipped that what you're seeing is normal.

Unluckily for flavoring php (and also python) ports there is no other
way than to change the package name to include the php (or python)
version  they are flavored as, which introduces a discontinuity in pkg
update work. Usually UPDATING file has some indication about this.

> 
> 
> Why it is not handled automatically like in other OSes?

The present infrastructure accounts different package names as different
packages, but flavoring requires a package name change in these
situations and there is no general was to discover which one of the new
flavors is the desired one anyway.

pkg manages automatically a lot of situation but from time to time
manual intervention is required. In my experience this holds true for
all OSes. Flavoring (especially php/python flavoring)introduces changes
which simply cannot be automated.

(The quantity of manual intervention changes from OS to OS and from time
to time, but that's also normal)

-- 
Guido Falsi <mad at madpilot.net>