Bug 11404

Most of macros were backported to rpm5 long ago. dnf stack is not buildable with librpm from rpm5. People from Mageia tried to make dnf work with rpm5 but it was not possible.

In place upgrades from 2016.1 to 2019.1 can _in theory_ be done by mount-binding to a chroot of rosa2019.1 ( https://abf.io/platforms/rosa2019.1/products/284 ), if you have time and wish, let's try to make such a script together

I'd be happy too. I have a far too sophisticated Rosa install to start fresh. I think part of the problem could be solved just by maintaining both urpmi and dnf synethesis hdlist for 2019.1. Allow the in place upgrade to work with urpmi and then switch to dnf once the upgrade is done.

(In reply to Zombie Ryushu from comment #2)
> I'd be happy too. I have a far too sophisticated Rosa install to start
> fresh.

Have a llok at kickstart files http://wiki.rosalab.ru/ru/index.php/Anaconda to automate reproducible deployment of rosa2019.1

> I think part of the problem could be solved just by maintaining both
> urpmi and dnf synethesis hdlist for 2019.1. Allow the in place upgrade to
> work with urpmi and then switch to dnf once the upgrade is done.

RPM boolean depencies are already used in rosa2019.1, OrderWithRequires is widely used, a large amount of work has been done to fix order of installing packages ina  big transaction (see https://nixtux.ru/1052), urpmi will neither understand OrderWithRequires, nor be able to install packages in a correct order, the order will be such that it may either be correct or not, like rosa2016.1. Dependencies from file paths like "Requires: /usr/bin/foo" or "Requires" /usr/share/metainfo" are already used, urpmi will not be able to resolve them too, there is a separate metadata with list of files which is understood by dnf.

I understand, just provide me with an (English) Procedure, I will follow it.

English please!

I'm not sure about the procedure, but I would do it. (Actually, I did it)
I just install the 2019.1 system with my own DE (Gnome) with a saved /home partition.
The next step was to install a few missing packages.

I would advise you to save rpm -qa > ~/my_package_list_2016.txt
Then install 2019.1 (possibly in a VM), do rpm -qa >~/my_package_list_2019.txt and compare the package lists for the missing ones or remember something.

On the other hand, it is planned to rename 2019.1 to 2021.1 in the near future. That is, it will be desirable to reinstall the system again.

Saving /home is not the only problem here, I have MariaDB and Samba Databases in /var/lib, and a ton of stuff in /etc.

I wish that Rosa 2016.1 could be sustained longer, until a solution is found, but I hardly get any updates for it anymore.

(In reply to Zombie Ryushu from comment #4)
> I understand, just provide me with an (English) Procedure, I will follow it.

Which exactly procedure? Upgrading from 2016.1 to 2019.1 has never been neither done nor documented.

I understand that reading in Russian is worse than in English but Google TRanslate usually does a great job translating. I am sure that you will undersdtand. Contributions of English versions of docs are welcomed.

(In reply to Zombie Ryushu from comment #7)
> Saving /home is not the only problem here, I have MariaDB and Samba
> Databases in /var/lib, and a ton of stuff in /etc.

You can use `rpm -Va` to detect files which differ from packaged ones (I am not sure that rpm -Va works in the sdame way in rpm5). And you can run something like:
find /etc -print | sort | while read -r line; do if ! rpm -qf "$line" 2>/dev/null; then echo "$line"; fi; done

Note!!! We do NOT support smooth migration of SERVER stuff from 2016.1 to 2019.1!
bind, apache and mariadb were dramatically changed, structure of their configs and their locations was improved, upgrades between major versions of mariadb were greatly improved. /srv/mysql was moved to /var/lib/mysql without making any script that would automate such migration because they are not easy to write and may fail and cause loss of data. Such migrations must be done manually and not by system upgrade.

(In reply to Zombie Ryushu from comment #8)
> I wish that Rosa 2016.1 could be sustained longer, until a solution is
> found, but I hardly get any updates for it anymore.

I will be kept a bit alive for a while. But server stuff is in bad form there. It is much better in rosa2019.1. And feedback from people who use ROSA as a server like you is very much appreciated.
By the way, there is a minimal server iso: https://abf.io/platforms/rosa2019.1/products/279

(In reply to Grigorev Andrey from comment #6)

> On the other hand, it is planned to rename 2019.1 to 2021.1 in the near
> future. That is, it will be desirable to reinstall the system again.

Why reinstal? dnf upgrade or dnf distro-sync will smoothly just reintall all rebuilt packages.

Have you looked at the Bugzilla lately?

(In reply to Mikhail Novosyolov from comment #10)
> Why reinstal? dnf upgrade or dnf distro-sync will smoothly just reintall all
> rebuilt packages.

Ten minuts for reinstall vs time of sync all packages

I have an incredibly complex configuration!

(In reply to Grigorev Andrey from comment #12)
> (In reply to Mikhail Novosyolov from comment #10)
> > Why reinstal? dnf upgrade or dnf distro-sync will smoothly just reintall all
> > rebuilt packages.
> 
> Ten minuts for reinstall vs time of sync all packages

start dnf distrosync and go away from the PC ;-) You will save time because will not have to fix configuration (of course if it was customized after installing an ISO)

(In reply to Zombie Ryushu from comment #11)
> Have you looked at the Bugzilla lately?

What do you mean?

(In reply to Zombie Ryushu from comment #13)
> I have an incredibly complex configuration!

It is time to make configuration reproducible! ;-)