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

[Giovanni Mariani]

On 28/12/22 14:59, Mikhail Novosyolov wrote:
> 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.
> 
Great news! I was just wondering when this would start...

The plan you propose is sound...
Some little remarks below for some of the proposed steps.

> 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.

For this one (and step 5 and 12), I think we need a place where put and 
interactively edit the "broken stuff" list to mark the packages being 
worked and fixed... just to avoid someone doing two time the same work.
In the past ABondrov used google docs, but perhaps there are better 
alternatives at hand...

>  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.
Perhaps this could be the time for also taking out from Contrib EOL 
stuff as qt4/(kde4)/gtk2/python2 packages or old and unmaintained 
packages having a newer alternative...
For the Sound packages (ie the ones I know about better), there are 
still a few of them...

> 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.

I'm basically OK with your proposal, but we could face two issues with it:
1) Finding packages that will not build, because they use some stuff not 
present in (or changed since) the libc/libc++ (probably more the latter 
than the former) coming with gcc 11.2.0.
I already found a such case with Ardour (I wrote you about this, do you 
remember?):
********************************
../gtk2_ardour/option_editor.cc: In member function ‘void 
EntryOption::filter_text(const Glib::ustring&, int*)’:
../gtk2_ardour/option_editor.cc:354:48: error: no matching function for 
call to 
‘std::basic_string<char>::erase(std::basic_string<char>::const_iterator&)’
   354 |                                 t = text.erase (t);
       |                                     ~~~~~~~~~~~^~~
[...]
/usr/include/c++/11.2.0/bits/basic_string.h:4793:7: note:   candidate 
expects 2 arguments, 1 provided
********************************
Every release >= 7.0.0 failed to build with this error related to the 
standard library headers.
Luckily it was only one single change in the Ardour sources, easy to 
find and to reverse, but IMO the thing could happen other times, as our 
gcc toolchain becomes older...

2) Gcc 14 (if not before) should disable by default or remove at all the 
support for a few compatibility features dropped by C99  and still 
supported (eg. implicit function declaration).
LLVM/Clang should get this at release 16.
See:
https://lwn.net/Articles/913505/
https://fedoraproject.org/wiki/Changes/PortingToModernC

Given the  big number of packages involved and the complication deriving 
from autoconf scripts using the deprecated features, this work could 
require a very long time to be finished. So, perhaps, we should start 
working with newer compilers and catch/fix all the fallout from them 
earlier than we would prefer... but I guess that we can start this just 
after releasing the new 2023.1.

Just my two cents...

GvM