[Devel-en] New platform: forking rosa2021.1 into rosa2023.1

[Mikhail Novosyolov]

Hi all! Happy New Year!

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.

First of all, I would like to summarize main (to my mind) achievements of rosa2021.1 compared to rosa2016.1:

  * We now have a stably and reliably working package system without regular breakages or RPM database and loops and mistakes in dependency resolution
  * We now have a stable and well working order of package installation in big transactions like building an ISO
  * OS can now be installed automatically and reproducibly by kickstarts and via PXE
  * OS images without graphics (a DE) can now be built and are built (server ISO, http://mirror.rosalinux.ru/rosa/rosa2021.1/iso/ROSA.FRESH.12/server/)
  * 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
  * Many odd dependencies from packages, forming the base system, have been removed, we now have rootfs in not a bad condition (http://mirror.rosalinux.ru/rosa/rosa2021.1/iso/ROSA.FRESH.12/rootfs/)
  * Two factor authentication, smartcards etc. are now well supported thanks to using GDM
  * More DEs are released officically
  * Server-side packages have become better maintained
  * Ready to use binary kernel modules are shipped now, without need to wait for dkms to compile them on host
  * Automatic installation of needed proprietary NVIDIA drivers via kroko-cli (https://abf.io/import/auto-krokodil)

I suggest the following plan:

 1. 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.
 2. Organize a working building of ISO images based on the new platform; fork branch master of ISO building sctipts (https://abf.io/soft/rosa-build-iso) into rosa2021.1 and rosa2023.1 and place a README in master telling to see one of the other branches.
 3. Organize http://repoclosure.rosalinux.ru for the new platform.
 4. Change RPM macros with platform version.
 5. 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.
 6. Update glibc and binutils (not gcc!)
 7. 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.
 8. Clean up packages with suffix rosa2019.1/rosa2021.1 where there will be the same package with the new suffix rosa2023.1
 9. [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.
10. 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.
11. Update python3 from 3.8 to 3.11
12. Make a mass build of all python-related packages, cry but try to fix them, at least buildability
13. Update Anaconda installer if needed due to problems with Python 3.11
14. Build ISOs with working Anaconda
15. Update perl
16. Rebuild and fix perl-related packages
17. Update ruby
18. Rebuild and fix ruby-related packages
19. <...>


Any ideas are welcomed.

I should probably write this plan here for discussion a bit earlier, but the fork is going to be done maybe even tomorrow.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rosalinux.ru/pipermail/devel-en/attachments/20221228/9516194c/attachment.html>