Renaming OpenMandriva repositories

Hello,

There is an ongoing discussion in contributors group with regard to renaming repositories and finally getting things in order.

We think /unsupported name may be misleading to newcomers. Actually there is a lot of good perfectly working packages there, which are well supported.

We are looking for proper names.

  • /main may stay /main, or to be renamed if any need;

  • /unsupported must change to something else (short, simple and not misleading);

  • the rest should be archived but still remain available if anyone wanted to use or fix-if-broken the stuff there.

Looking forward to read your suggestions.

Please notice:
I started this topic in Support category so that everyone can participate.

As we discussed on IRC I think the best solution is to move supported packages from unsupported to main and remaining cruft from main to unsupported. Thus we make unsupported truly unsupported packages. As in “package has no maintainer”. OFC we can move packages in unsupported to other repos if and when they become supported. (Which probably happens if/when more people in Community decide to volunteer to be package maintainers.)

1 Like

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.

With regard to current ‘/main’ repo I’d suggest to split the packages there into 2 different repos.

-1. ‘core’ (or whatever) containing all core packages and their deps
-2. ‘main’ (or whatever) containing the rest of working stuff.

The experience we are facing right now with mass-rebuilds of 25000+ packages imo should really make us consider some kind of solution.

I’d suggest also that the packages in current ‘/unsupported’ working and provided of their proper source be moved to the ‘main’ (or whatever) repo once updated or rebuilt.

There is a suggestion to rename unsupported repo to ‘UMR’ (as in unmaintained repository) where all the obsolete/not-working/unknown/junk stuff can be dropped or left there.
We may drop there also the cruft that someone told we have in /main.

While discussing of repos, there is also a suggestion to enable /restricted by default, with a warning telling the users about the possible local laws infringing.

I’m new here and I may not have the wisest suggestions, but from my outside limited knowledge on what’s happening, I do have some things to suggest.

rugyada I agree to split the repos from main and have it be called core and main. Both main and core be enabled by default with an option to enable extra. There could even be an extra repo. The extra packages can possibly hold more shell packages or other packages that aren’t in the repos like zsh auto suggestion and syntax highlights. Dnf of course pulls packages from all repos that are enabled so I don’t know if this would be an issue to do.

As for legacy packages or broken ones, they could all be moved to a repo called legacy and a description of that can be that 'We do not support legacy packages. Use them at your own risk"

Restricted repos can be a recommendation in the welcome app with a warning if thats not the default behavior already

Community packages can have their own repo for approved community repos built from abf.

This is just my idea, I don’t think its the best but its what I can gather from the limited knowledge I have on whats going on.

or even in an ‘extra’ (or whatever) additional repository ?
Description may be: packages formerly included in (or coming from) /unsupported that are believed to work currently without any fix.
The aim is always to not overcrowd the ‘main’ (or whatever) repo.
(thinking out loud)

Over the last years I also have been building packages for unsupported repository because without this repos simply I can’t use OMLx for my own needs. I don’t know so much about AFB failure but I also think actually unsupported repository is the main problem and not only for its name so I mostly agree with @AngryPenguin’s analysis.

The fist step is to understand how to upload missing sources to ABF. Actually one always should download sources on local machine then upload them with abf put command or by means of filestore web interface. This also means no automatic upgrade is possible, even if in many case ideally this will works (eg. most python libs). An alternative solution (I don’t know if it is possible and how many work it requires) may be let ABF downloads sources by itself directly from upstream url provided in the .spec file in git repo without the need to upload them from local, provided that .spec anf .abf.yml have been updated before. I also noticed some other distros are beginning to use gpg signature when provided and in this case .abf.yml file could be updated automatically by ABF itself.

Once sources problem is fixed, the second step is about how to reorganize all repositories. In fact having two repository (actually main and unsupported) without a clear distinction between them is pointless and may confuses users. My opinion is unsupported repository could exist only if it real differs from main in some way. Stated that core packages (I mean at least all used for a standard installation) are in main repository, in the spirit of a community driven distro, a simple criteria for all other packages could be to distribute them between main and unsupported with respect to the frequency they receive updates: for example before a mass rebuild before a new release, all non core packages have been updated in the last, say, two years could be moved in main repository, other in unsupported. Packages have not received any updated since the previous releases or have been broken for last, say, two years, could be dropped out. In this way constantly broken packages in main and unsupported will be clean up automatically. Maybe this example is too simple for a real case it makes clear to the user packages in main are really supported while packages in unsupported are still actually working but on the way to exit from repository, so if he know he will need some of these packages for the future he could/should activate (at least he could open a upgrade request). I disagree with having a repository with totally junk or orphaned packages because is a logical non sense, a waste of space on servers and from the point of view of an user a packages fails to install is more frustrating than not to find it in repo.

Once it is clear packages in main and unsupported have a different update policy it is also clear main repository contains fully supported packages and unsupported contains packages need someone who cares about. So is more simple to apply a naming schema. I suggest two:

classical:
mainmain
unsupportedarchive (or extra or contrib)
restrictedrestricted
non-freenon-free

where archive refers to things no more so useful will be trashed in a near future, extra refers to things should not be here but are because someone cares about and contrib means “packages looking for contributor to survive”.

openmandriva:
mainproton
unsupportedneutron
restrictedrestricted
non-freeelectron

this because codename used for release is a name of an atomic element whose kernel is made by proton and neutron. Of course I associate electron to non-free because bot are negative in some way :slight_smile:
But I can’t find a satisfactory new name for restricted so I end with a question: is it really useful? I mean other distro still uses this and these packages are still under patents issues?

i will just speak about manjaro repositories ( and arch and AUR )

from Manjaro we have
[core] ( as main )
[extra] → addition and update from dev ( not from Arch , can be AUR or dev )
[community] → version for others isos build community ( not Xfce , KDE , Gnome , all others)
[multilib] → for 32 bits / 64 bits

we have also 3 levels
Stable <— Testing <— Unstable < – Arch Stable

if sources are not updated or lost maintainers
it goes in extra or community

for arch , it gos to AUR , there is all state in AUR ( obsolete , orphans , activies )
version test are named - < source-git >

from manjaro , in some case also in drop in AUR , for obsolete or orphans

in you case unsupported will look like AUR , be very careful on that
may be you want to have
extra or contrib ( only active and build ok )
or
unsupported ( build , obsolete , orphans etc … )

I mean more about creating a special place eg in ABF where those inoperative packets would be moved. This would not be a repository, but a separate place for projects in ABF related to github entries, for example.

This means that they will still be available to openmandriva team, e.g. if someone wants to bring the package back to life. Then without having to create everything from scratch (github, abf projects, adding to repo etc).

Yes, maybe I was not so clear on this point. About orphaned packages I think they should not be in any rpm repository user can use but the project could still be in ABF and .spec, patches and other stuff should still remain in git repository.

This is exactly what I think about.

Also maybe we could highlight the possibility far a user to have a personal repository too (I liked and used this feature a lot before dnf was adopted).