Re: package upgrade strategy

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

Hi All,

Thanks again for all the answers in the topic! I read all of them but I cannot answer each in separate emails so I just picked the latest to continue the thread.

As earlier mentioned I agree with the advantages of the pkgsrc based solutions and in the meantime I also found a nice summary of the different approaches at https://wiki.netbsd.org/pkgsrc/how_to_upgrade_packages/ (better later than never). However, I pursued the issue further to get a workaround (till I have time to rebuild things via pkgsrc) with the binary packages and I think I found something based on which I could build something.

I only tried it manually and it seems to work but of course in case of more pkgs a script would be better to manage all this:
-in case a package needs to be updated to a newer version, copy its shared libs to a specific directory (say soold)
-record the old pkg name (together with the one that required updating it) in an sqlite db and the files copied to the soold directory
-add soold directory to LD_LIBRARY_PATH if it's not yet added

The solution would be better if it was somehow possible to revert the changes i.e. if I don't like the newly installed stuff, i.e. just downgrade the packages to their earlier versions which could be figured out from the db file that keeps track of the removed pkgs. However, afaik binary pkg downgrade is not possible either pkgin or by the pkg_* tools.

I guess this is against quite a many things and how they're meant to be done in NetBSD but as a workaround this may come handy. What do you think? Can anyone forsee already a "design flaw" or whatever that'd prevent this from being feasible?

Thanks & regards,
r0ller


-------- Eredeti levél --------
Feladó: Greg Troxel < gdt%lexort.com@localhost (Link -> mailto:gdt%lexort.com@localhost) >
Dátum: 2017 szeptember 30 18:09:06
Tárgy: Re: package upgrade strategy
Címzett: r0ller < r0ller%freemail.hu@localhost (Link -> mailto:r0ller%freemail.hu@localhost) >
 
pkgsrc is designed, more or less, to have packages built consistently
from the same source tree. You can often get away with having some
packages be old. Other than the old packages not depending on or being
dependencies of newer ones, you're on thin ice.
If a package is not available in a newer branch, that could be because
it was removed from pkgsrc, or because it didn't build. You can check
out the sources and have a look. You can also look at the mail archives
for pkgsrc-bulk and see what happened, and find the build logs. It may
be that midori builds on NetBSD 8 (not yet out) but not 7, or 7 but not
6. This can be about the versions of X things in the base system, or it
can be about compilers. So looking at the build logs for various
systems can be useful.
pkgsrc does not require you to choose between building from source and
binary packages. But, you should use a source tree consistent with the
binary packages you are using. Right now I think the latest binary
packages for NetBSD are from 2017Q2. 2017Q3 exists in source form (and
I'm behind on drafting an announcement), but NetBSD's package building
machines are down due to data center work (we are grateful guests). I
expect binary packages within a few weeks.
Also, you can build your own binary packages, and use them with pkgin.
You just have to make a summary file, which is easy.
pkg_info -X *gz | bzip2 > pkg_summary.bz2
So if you have a fast machine, you can build, and install them on the
slower machine (just rsync them and add a repositories.conf line).
Packages without active upstreams are harder to maintain and can tend to
run into problems. Midori's last release appears to be from August of
2015. That's not really really old, but it's long enough to suggest a
possible issue. If you want to run an older build of midori, it's going
to expect dependencies that are ABI-compatible, and this rapidly gets
difficult.
Overall, I think your best (but not easiest) path to success will be to
use 2017Q3 sources, update everything you can via the forthcoming binary
packages, and then to build midori from source, perhaps fixing the
build. We would then want to commit the fixes, and for anything that
belongs upstream to be comitted there and then have a new release. So
far it looks like the patches in pkgsrc for midori are very minor and
not obviously appropriate for upstream.