Hi. I was wondering what to do with it.
Unfortunately for me it does not look easy, especially since everything is getting complicated.
In fact, hardly anyone on the team has been building packages for contrib / unsupported over the last few years, except me and probably one more person. Therefore, I allow myself to express my opinion.
I have considered many scenarios, but in light of recent events, I think that:
1. All decisions about the unsupported repository should be suspended.
Why? Well, after recent observations, I can see that the repository is somewhat damaged. After the last major ABF failure, many sources were deleted (lost). Some of them were recovered but mostly in the main repo, but it seems that most, maybe even about 90% of the sources for unsupported packages are lost.
This even applies to relatively new packages, which I have maintained myself and updated in the last two years or maybe even a year ago. Their sources are gone. Which could mean two things, we either try to get them back or we just close this repo. The decision is not mine, although the quickest and probably the easiest way is to close the repo and get rid of the problem, but if you decide to close the repo, I am convinced that I should finish my adventure with OM then - I myself put in too much work to now allow it to close. Also trying to manually restore it by myself is too hard, even only my packers, which I have been keeping for over 3 years, are too heavy and I would not be able to cope with it, and I would probably run out of time in my life.
2. Letâs try to recover the lost sources first.
After talking to bero, I know that getting back the sources may not be easy from the original media. Therefore, the idea is to run a script to automatically update packages in an unsupported repo that could restore these deleted sources immediately, provided the source0 tag in the .spec ofc if url is still valid and up-to-date.
3. Having recovered sources, or at least some of them, we can do a mass build.
Doing a mass build without trying to restore sources is pointless. I think about 90% of packages would fail due to lack of sources.
4. Change the repo name to eg âextraâ or "community"
I insist on the former. And also make the repo enabled by default in the system so that new users have easy and unrestricted access to it.
5. Create a new junk source and name it âorphanâ or âdeprecatedâ.
Packets that are permanently broken would be manually transferred to it. Like, for example, packages that require qt4 (which is no longer available) and others like that. Such packages that no longer compile or function correctly. But from this repo they could be moved back to a working repo like âmainâ or âextraâ then if they had an update, fork or author decided to resume their life, or there was an easy way to fix them.
A word of conclusion I donât think itâs a very good idea to move packages from unsupported to main in the current situation. It would be time consuming and many of them have lost their sources. It would be hard to separate the good ones from the bad ones considering that many of them also have dependency coils in the same repo and they may be fully operational but due to the corrupted sources it would not be possible to rebuild them - which would do more problems than good.
While the repo itself, despite the missing sources, works in LX 4.3 and Rolling, unfortunately, after updating toolchains and python 3.11 in Cooker, it is seriously damaged and any interference we have considered so far does not make any sense - in my opinion.