Testing dependencies of critical packages (list) for AstroArch before updating

[sc74]

No description provided.

[MattBlack85]

@sc74 I like this change, but I think the actual form is a half baked one. Why we don't do directly ldd /usr/bin/foo on those binaries and check after the update if any linked library cannot be found? That would give us a very specific information (and a real one).

Blocking an update only because some of the deps have changed seems to be a lil excessive

[sc74]

I understand your reasoning, but my approach is different. If, during the update test, dependencies break one of the packages in the defined list (packages you maintain), and you haven't recompiled them, then we block the updates and provide a notification explaining the reason (which you can modify as needed for reporting). Users will be less frustrated by a failed update (more opportunities for astronomical observations), and you'll have more time to fix it. What do you think?

Another thing: the script saves a list of all the system's packages before the update. This could help us with debugging and perhaps also for a future script to automatically repair the system.

[MattBlack85]

this is a logical bug likely. In every loop you set found_risk to 0 and here, outside the pkg loop, you check the flag. If the last package will return found_risk=0, this won't block anything

[sc74]

Yes, the variable should be initialized before the loops. Could you make the change? Otherwise, I'll look at it this evening after work.

[sc74]

I just fixed the variable positioning error and added the display of packages and dependencies with their conflicting versions. You can also modify the list of packages to check if you see a missing package