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 < g...@lexort.com (Link -> mailto:g...@lexort.com) > Dátum: 2017 szeptember 30 18:09:06 Tárgy: Re: package upgrade strategy Címzett: r0ller < r0l...@freemail.hu (Link -> mailto:r0l...@freemail.hu) > 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.