<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi all! Happy New Year!</p>
<p>Quite a lot of time has passed since release of first ISO images
based on rosa2021.1 and even more time since its development was
started. Now it is time to create a new platform, while continuing
maintenance of the old one.<br>
</p>
<p>First of all, I would like to summarize main (to my mind)
achievements of rosa2021.1 compared to rosa2016.1:</p>
<ul>
<li>We now have a stably and reliably working package system
without regular breakages or RPM database and loops and mistakes
in dependency resolution</li>
<li>We now have a stable and well working order of package
installation in big transactions like building an ISO</li>
<li>OS can now be installed automatically and reproducibly by
kickstarts and via PXE</li>
<li>OS images without graphics (a DE) can now be built and are
built (server ISO,
<a class="moz-txt-link-freetext" href="http://mirror.rosalinux.ru/rosa/rosa2021.1/iso/ROSA.FRESH.12/server/">http://mirror.rosalinux.ru/rosa/rosa2021.1/iso/ROSA.FRESH.12/server/</a>)</li>
<li>System is still installed quicker than most other Linux
distros thanks to rsyncing instead of a per-package
installation, and the new installer allows to make settings and
then do not be disturbed by further questions what saves time</li>
<li>Many odd dependencies from packages, forming the base system,
have been removed, we now have rootfs in not a bad condition
(<a class="moz-txt-link-freetext" href="http://mirror.rosalinux.ru/rosa/rosa2021.1/iso/ROSA.FRESH.12/rootfs/">http://mirror.rosalinux.ru/rosa/rosa2021.1/iso/ROSA.FRESH.12/rootfs/</a>)</li>
<li>Two factor authentication, smartcards etc. are now well
supported thanks to using GDM</li>
<li>More DEs are released officically</li>
<li>Server-side packages have become better maintained</li>
<li>Ready to use binary kernel modules are shipped now, without
need to wait for dkms to compile them on host</li>
<li>Automatic installation of needed proprietary NVIDIA drivers
via kroko-cli (<a class="moz-txt-link-freetext" href="https://abf.io/import/auto-krokodil">https://abf.io/import/auto-krokodil</a>)<br>
</li>
</ul>
<p>I suggest the following plan:</p>
<ol>
<li>Fork rosa2021.1 to rosa2023.1. We will not increase Release
tags and will not make a mass rebuild right after the fork
because it is not needed (unfortunately, a mass build is still
not the quickest thing to do). Not increasing Release tags will
allow to merge git branches easier.<br>
</li>
<li>Organize a working building of ISO images based on the new
platform; fork branch master of ISO building sctipts
(<a class="moz-txt-link-freetext" href="https://abf.io/soft/rosa-build-iso">https://abf.io/soft/rosa-build-iso</a>) into rosa2021.1 and
rosa2023.1 and place a README in master telling to see one of
the other branches.</li>
<li>Organize <a class="moz-txt-link-freetext" href="http://repoclosure.rosalinux.ru">http://repoclosure.rosalinux.ru</a> for the new platform.</li>
<li>Change RPM macros with platform version.</li>
<li>Not making any other changes in packages, make a mass build
without publication. The goal is to get a list of not buildable
packages. To make it faster, we may build part of the
repository, e.g. contrib, on aarch64 and another part (e.g.
main) on x86_64.</li>
<li>Update glibc and binutils (not gcc!)</li>
<li>Make a mass rebuild (with publishing of results into the
repository, packages will have a new suffix/disttag rosa2023.1).
Find which packages stopped being buildable compared to the list
from point 5. It will give us a list of packages broken because
of glibc and we will be able to quickly fix common problems
without spending time on classifying each problem.</li>
<li>Clean up packages with suffix rosa2019.1/rosa2021.1 where
there will be the same package with the new suffix rosa2023.1</li>
<li>[in parallel with other things] Reformat main and contrib.
There are many strange, old, not maintained, not used packages
in main. We have to form the new main repository from packages
which are used in ISO images, plus some server packages plus
some other packages and all packages required to build them,
recursively. All other packages should go into contrib. Here we
will have to take installed_pkgs.log.gz from build lists of mass
build and some how process them with a script.</li>
<li>We have gcc 11 in rosa2021.1, gcc 12 is the latest version,
gcc 13 is going to be released in spring 2023. I do not see
sense in updating gcc now. Updating it from 11 to 12 will break
building a lot of packages but will not give any profit (at
least nothing comes to mind). I suggest to make other big
updates for now and wait, maybe we will better update to v13
nearer to its release.</li>
<li>Update python3 from 3.8 to 3.11</li>
<li>Make a mass build of all python-related packages, cry but try
to fix them, at least buildability</li>
<li>Update Anaconda installer if needed due to problems with
Python 3.11</li>
<li>Build ISOs with working Anaconda</li>
<li>Update perl</li>
<li>Rebuild and fix perl-related packages</li>
<li>Update ruby</li>
<li>Rebuild and fix ruby-related packages</li>
<li><...><br>
</li>
</ol>
<p><br>
Any ideas are welcomed.</p>
<p>I should probably write this plan here for discussion a bit
earlier, but the fork is going to be done maybe even tomorrow.<br>
</p>
</body>
</html>