[lug] Finding and removing obsolete packages after system upgrade

[Bear Giles]

Just use a really minimal installation and work in a docker container. It's
really easy to go back to an earlier version. :-)

I'm actually doing that now - but with virtualbox - for my java development
at work. It's a monster app and it's been a nightmare keeping all of the
dependencies straight. My life got a *lot* easier when I moved into a
virtualbox instance where I download the source from github and then run an
ansible script to install all of the tools and libraries used by the other
components of our platform

I plan to go a step further and just use docker containers for the other
components. I haven't had any problems building the docker images but I
don't know the magic values in the magic configuration files to get the
docker containers to play together. The normal dev setup assumes everything
is available on localhost but using 'host networking' doesn't work right.

On Wed, May 6, 2020 at 2:38 PM Davide Del Vento <davide.del.vento at gmail.com>
wrote:

> Not really an answer to your question, but something to mull on....
>
> Because of this and similar issues I do not do any system upgrade anymore
> (I just update individual packets, obviously). During the overlapping time
> between one version going out of support and the new one being ready for
> installation, I make a separate, fresh install of the latter. I always set
> up partitions in a way to ease this process: two partitions mounted
> respectively as / and /old-os similar to a double-swapping-buffer (during
> the brief overlapping period, the /old-os on the old system actually points
> to the new system which replaces the "very old" one, but that's not a big
> deal). During this transition time, I do multi boot. If I don't like
> something in the new install, the old, untouched one is just a reboot away.
> I used to share home directories, but ran into troubles there too (new
> versions of software getting "crazy" about old format of data which their
> former selves saved in home). So that has led me to do something similar
> for home directories too.
>
> I've found that just dealing manually with what I need to preserve is
> waaaaaaay easier and more robust than upgrade-and-pray. Plus, gives lots of
> peace of mind since the old version is untouched and available so I am more
> aggressive in trying new things for the new install -- and wipe it out if I
> don't like them.
>
> As I said not an answer, YMMV. Just $0.01 (half than usual...)
>
> Cheers,
> Davide
>
> On Wed, May 6, 2020 at 1:10 PM Jonathan Eidsness <
> jonathan.eidsness at gmail.com> wrote:
>
>> Hey Everybody,
>>
>> Docker broke on my recent system upgrade to Fedora 32 as a result of
>> having oci-systemd-hook installed (which was obsoleted some time ago).
>> Removing the package fixed my issue, but now i'm left wondering what other
>> obsoletes are hiding in there.
>>
>> Does anyone know if there's a way to query dnf for packages that aren't
>> found in any upstream repositories anymore? A list of packages that have
>> been obsoleted in fedora would be a good option as well.
>>
>> I've tried dnf list --obsoletes, but it looks like it only returns
>> really recent obsolete versions of packages or dependencies that have
>> version conflicts, etc.
>>
>> Jonathan Eidsness
>> _______________________________________________
>> Web Page:  http://lug.boulder.co.us
>> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
>> Join us on IRC: irc.hackingsociety.org port=6667 channel=#hackingsociety
>
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> Join us on IRC: irc.hackingsociety.org port=6667 channel=#hackingsociety
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20200506/3a80ec78/attachment.html>