Old and new libraries and how they affect updates

[Archie]

Over the course of my time upgrading KDE, there's always an issue of packages being removed that needed to be reinstalled or packages being removed which becomes incompatible with an upgrade. So, I solicit an explanation from one of our enlightened gurus, TerryN. I hope to convey his explanation in the hope that or users would understand why things are in such a way. I don't know how else to work around the issue but I do remember that pinoc created a script that would detect the apps that would be removed upon an upgrade and reinstall those apps again. Perhaps that would be the solution.

Anyway, here's an excerpt from our correspondence:

Archie: How do I prevent other install packages from getting removed when I update a package? It is happening again. I just packaged kdelibs-4.9.3 and when I try to update 4.9.2, it wants to take out a whole bunch of 4.9.2s plus others. Is there a way to go around this and only get kdelibs-4.9.2 and kdelibs-devel-4.9.2 updated to 4.9.3?

TerryN: The packages get removed because the new package doesn't provide a library dependency that they NEED.  This is usually because a library ABI version (called %major in the SPEC file) has changed.  For example the old package has libfoo.so.8 and the new package has libfoo.so.9 but the dependent packages NEED libfoo.so.8. The upstream developers change the ABI version when they make a change which is NOT backward compatible (which means applications built against libfoo.so.8 will not work with libfoo.so.9). Therefore there is no choice but to rebuild the dependent packages against the new version of the library (or re-engineer KDE to make the libraries co-exist).  They can still be the same 4.9.2 packages but they need to be rebuilt with kdelibs-devel-4.9.3 installed instead of kdelibs-devel-4.9.2.

So the short answer is NO.  There isn't a way around this without significantly re-engineering KDE.  Much easier to rebuild the dependent
packages.

Archie: It should be easy enough to get a list of dependents and up them a release number and updates should run OK. Am I correct in assuming that?

TerryN: I would think they will install OK but whether they will play nicely together or not is another matter.  I've always had the impression that the KDE devs work on the assumption that the whole SC (or at the very least each module) is kept at the same revision level.

As I've mentioned on another thread, 4.9.3 and 4.9.4 will not be made available, and testing will resume on maybe 4.10 (Jan 23, 2013) and definitely 4.10.1 (Mar 5, 2013). Before this stage, I will contact pinoc, and if he willing to work together and improve his KDEupgrade script, this may solve KDE's big problem.

Once again, thank you, Terry for you valuable insight and explanation. It is much appreciated.

Peace and much respect,
Archie

[TerryN]

I do remember that pinoc created a script that would detect the apps that would be removed upon an upgrade and reinstall those apps again. Perhaps that would be the solution.

Not really.  That was a different problem.  There still has to be NEW versions of the apps to (re)install.  The script was needed because the package names had changed and so the packages were not being automatically updated.

Terry

[pinoc]

yes, correct. 

[Archie]

Yes, that is correct. What I wanted to suggest was an improvement on his KDEupgrade script that would take a list of apps and libs that would be marked for removal when an upgrade is indicated ... install the upgrade then reinstall the apps that were removed. I am aware that there are still problems with this idea such as if a removed app/lib will not be reinstalled due to errors ... but that would be part of the improvement. I don't know whether this is feasible and doable but I'm sure its worth our efforts to see what we can achieve to give our users a better method of upgrading.

[TerryN]

Yes, that is correct. What I wanted to suggest was an improvement on his KDEupgrade script that would take a list of apps and libs that would be marked for removal when an upgrade is indicated ... install the upgrade then reinstall the apps that were removed. .

As I said in the email exchange, if apps are being removed it is because their dependencies are no longer met.  If their dependencies are not met they can't be re-installed.  I can't see what you want the script to do.

Terry

[Archie]

I gotta find all the solutions I that could, and perhaps adapt a couple. There are apps and libs that would reinstall after being removed by a lower version. I'm not sure why they are removed in the first place then could be reinstalled after an upgrade.

My real problem is I could only get a list of apps and libs that would be removed on an upgrade. But that wouldn't be a complete list. Also, it won't be the same list as everyone's.

It would be much simpler to just warn users of the upgrade but if there's something else that we could do, I would certainly like to explore it.

I have already started with KDE 4.9.3 ... got kdelibs-4.9.3 built last Nov. 8th ... but stopped short of installing/upgrading and building the rest until there's some sort of direction to go.

The KDEupgrade script will need some major body work and I'm sure that would be a lot to ask of pinoc ... or whether he'd even have the time to do it. I basically want the script to save on a file the apps and libs that an update would remove, continue with the update, and reinstall what it could from the list ... probably even creating a yad dialog stating that such and such app/libs were not reinstalled; please report to the devs. I know it's a very tall order ... and maybe it's not gonna go beyond just "talk". 

[TerryN]

IMHO that sort of thing should be part of the testing process.  End users (and the stable repo) should only get a full set of packages with all dependencies satisfied.  

Terry.

[Archie]

While it was overall satisfactory during the testing of 4.9.0rc2 and 4.9.2, the inconvenience still remains. If all users were like the testers, there wouldn't be any problem but the sad fact is that there are still users who will fail on updates.

IMHO that sort of thing should be part of the testing process.  End users (and the stable repo) should only get a full set of packages with all dependencies satisfied.

Any solutions will be a part of the testing stage. As with the usual KDE cycle, the most stable release would probably put us next on 4.10.2 or 4.10.3.

Any other ideas on how we could address the removals-on-update issue?

[kjpetrie]

rpm -qa --qf \\n\\t%{NAME}\\n -R > depsfile will give a list for what's installed in a file you can then search for the library version.

There will be a blank line above each indented package name. If this were then written into a script testers could be asked to run on their machines and then send back the collected info...