In yesterdays TC-Meeting there was discussion about what, if anything, to do about Contrib repo. Even though I did express opinion and make a suggestion or two, I’m not locked in to any position yet.
For one thing I’m not a developer. Looking at this from a user perspective I see nothing wrong with Contrib except that it appears to have a huge number of packages that don’t work. But I know of no packages that I give a flip about that don’t work at the moment so it isn’t really a problem for me as a user.
So I thought to back up and ask 2 critical problem solving type questions we use in business. Basically I’m asking developers and package maintainers to answer these questions and thus begin the discussion of what to do about Contrib or to leave it as is.
What is/are the problems with Contrib repo?
Why are these issues a problem?
It is probably common knowledge that some people, AFAIK devs and maintainers, have been complaining about Contrib, AFAIK, going back to Mandriva days. I suspect answers to the above simple questions would lead to what, if anything to do about this.
Contrib repository is somewhat abandoned.
In Main we have 7,5k of projects, and we do not have sufficent man power to handle that amout of packages.
Contrib has extra 8,3k of projects.
Even if contrib mass rebuild happens, there will be like 60% of failed packages. That means someone needs to fix them. Any volunteers ?
Now do the math. It took like two years till now, to get in shape for main repository for 4-5 active developers.
If contrib is in bad shape, maybe we should un-activate it?
What is the need for contrib repo (i mean, before it made sense for Mandriva official packages, and community packages, but today we all are community right?
Or maybe we need to push alternative repos for people wanting to maintain their set of packages - if they exist? (I mean the personal repos in ABF)
Packages in contrib are very different. Some are really useful - e.g., 0ad game or qmmp player. Even though they can be a bit outdated. It’s a good question though why not move such packages into the main repo.
There are some packages that should be definitely removed - e.g., a set of howto-sgml-* that contain 12year old hits&tricks for Linux.
Btw, the mostly notable set of packages in contrib are perl modules - there are 1700+ of them atm. I think most of them can be safely dropped - we should detect which of them are really required by some applications.
I can try to perform some preliminary contrib cleanup in the same way as we did in ROSA some time ago if it is ok for everyone.
In this case I think there should be an easy way to add personal repositories (the old urpmi.addmedia [...] )
We can also find a place (a new forum category for example) where the contrib people can announce their packages or new releases and talk with the other users.
Maybe just mass rebuild for contrib repo, then fix/update the most important packages and those that can be easily/fast fixed and other old/deprecated or those that are hard to fix just drop from repo.
Anyway common sense suggests first of all to focus on /main so to be able to publish a good release asap. After, there will be time to take care of /contrib.
I don’t think so, there’s some good and important packages in it. Of course we should move a lot of those into main…
The way I see it, we try to keep stuff in main working, while contrib is “if it breaks, you get to keep both pieces”.
IMO we need to go over the package lists and move some stuff from contrib to main and some other stuff from main to contrib (IMO most g* stuff would be better off in contrib, for example).
That could work, but would have the down side that it’s harder to collaborate – contrib is a collaborative effort, while for example I can’t push an update into TPG’s personal repo and he can’t fix something in mine…
Right. There are a lot of multimedia packages. I updated some ot them. Many of them are still developed and popular for example Rawtherapee, Lives, Darktable, Bleachbit, Dosbox, Flowblade, Fotoxx, PlayOnLinux and etc.
We should not abandon packages like these and similar ones.
Agree but I think that on Lx4 release let gnome still be in main. We’ll think about throw them out of main for lx5?
In addition, many packages of gnome are often used, even outside the gnome environment. itself.
BTW. I updated a lot of packages from gnome stack to latest 3.30.X version. From gnome-minimal pending only one - terminal, currently in 3.28.x version (new one 3.30 need import some packages).
Most of packages from task-gnome (and many dependencies) is ready and updated to latest.
I think that if someone from the developers spent some time this gnome would be fully operational.
Is broken. It still not use DNF repo, so I can’t even test new packages which I would like to import.
Up to now I’ve dropped ancient howto-sgml/text, few perl modules (though which are provided by perl itself and have newer versions) and R-* modules. The latter were not updated for years and useless in their current shape, so it’s more reliable for users to manually build/install necessary modules on their machines. R provides an easy way to do this (Installing R packages | R-bloggers).
