Re: package upgrade strategy

[r0ller <r0ller%freemail.hu@localhost>]

Hi Brad,

I'd do that if it was possible (having the newest versions of all my packages) but as said, midori is not available any more in the 7.1 package repo so it cannot be upgraded (not even the same version of midori is available with just an updated list of dependencies) and if I upgrade icu (to version 59), midori starts complaining about not finding the earlier version of it (version 58). What if I just used pkg_add for icu-59? Or if I mark icu-58 non-autoremovable by pkgin, would the install of icu-59 leave icu-58 untouched?

Best regards,
r0ller

-------- Eredeti levél --------
Feladó: Brad Spencer < brad%anduin.eldar.org@localhost (Link -> mailto:brad%anduin.eldar.org@localhost) >
Dátum: 2017 szeptember 28 14:13:53
Tárgy: Re: package upgrade strategy
Címzett: r0ller < r0ller%freemail.hu@localhost (Link -> mailto:r0ller%freemail.hu@localhost) >
 
r0ller <r0ller%freemail.hu@localhost> writes:
> Hi All,
>
> I hope someone can give an answer to this question from a newbie: how can I handle situations when an already installed package (say A) needs to be upgraded due to a newly installed package (say B) as it's being a dependency for it but another already installed package (say C) still needs the older version of package A? Upgrading package C may be thought of as help but it disappeared from the 7.1 package repo and as far as I could see it was last present in 7.0_2017Q1.
>
> If anyone is interested in the details, package A is icu, package B is seamonkey and package C is midori. What I did for now was that I changed /usr/pkg/etc/pkgin/repositories.conf so that it points to 7.0_2017Q1 and installed seamonkey from that repo as the versions are not that different (seamonkey-2.46nb7 in 7.0_2017Q1 and seamonkey-2.46nb8 in 7.1) and it left icu untouched. By the way, what kind of difference is indicated by the number in the 'nb<number>' suffix? Another question would be if it's possible to keep different versions of a package installed? I know in case of shared libs it may be tricky because of the symlinks but the runtime linker is not looking for the symlink I hope but the versioned soname, right? Any hints are welcome!
>
> Best regards,
> r0ller
Hello...
I have been running pkgsrc for a very long time and you won't like my
answer....
Basically, you don't try to do this with piecemeal updates.
It honestly will be simpler to delete all of the packages, saving
configs first, and reinstall the new versions. This may sound quite
extreme, but if you have the situation you describe there will be too
many other interdependencies to make anything else reasonable and sane,
especially in the long run.
There are techniques to make this much less harsh then it would be
otherwise, and I can tell you about them if you want, but I really
suspect you will find it much simpler to do as I suggested.
--
Brad Spencer - brad%anduin.eldar.org@localhost - KC8VKS
http://anduin.eldar.org - & - http://anduin.ipv6.eldar.org [IPv6 only]