Project

General

Profile

Housekeeping #3258

Merge [kernels] and [java] into [pcr] - delete unused repos

gap - 7 months ago - . Updated 7 months ago.

Status:
open
Priority:
discussion
Assignee:
-
% Done:

0%


Description

Merge [kernels] and [java] into [pcr]

This would reduce the number of repos which have to be enabled, thus simplifying installing packages and the maintenance burden on the wiki.
Moreover, having separate, tiny repos for very specific things is not consistent with our policies for repos in general; it is confusing that these things are somehow so special they need their own repos, unless I am missing something here.

Remove dead repositories

Corresponding abslibre directories:
- retired/
- unmaintained/
- ~*/
-- aurelien/
-- lukeshu/
-- megver83
-- smv

History

#1

Updated by gap 7 months ago

Moreover, java/byaccj appears to be a duplicate of pcr/byaccj, although the former is only available for x86_64, whilst the latter is available for both x86_64 and i686.

#2

Updated by bill-auger 7 months ago

  • Priority changed from bug to discussion
  • Description updated (diff)
  • Subject changed from Merge [kernels] and [java] into [libre] and [pcr] respectively to Merge [kernels] and [java] into [pcr] - delete unused repos

"special" things are special because they do not apply to most usual cases - in this case, most parabola users do not run any java programs and do not use any of the extra kernels - people only need to enable those special repos if they have special reasons - we are actually considering to add a few more repos for other special cases

this may as well be asking to merge pcr and libre - all of those java packages and extra kernels could go in PCR; but PCR is yet another special repo - packages in PCR are optional - parabola users do not need to have PCR enabled - [core] and [libre] are the only required repos - that is why things are separated - the separation is helpful and meaningful - IMHO, to merge them would be the opposite of "housekeeping" - it would be making clutter - separating special packages out of the main repos reduces clutter

whoever maintains them is probably the one who created those repos - i have never packaged any java programs myself; so i dont know why that repo exists - probably, none of those package are needed

i know that the kernel maintainer wants the kernels repo - it is not a bug which needs fixing; and there is no real policy about repos; so we would want to discuss it with him

#3

Updated by bill-auger 7 months ago

WRT tha "dead repositories" - who says they are dead?

the ones named like ~lukeshu and ~megver83, those are personal repos for each parabola team member - they exists for putting anything which is not yet ready for parabola, or is not interesting to any parabola user - they are like personal github repos

these things were put in place a long time ago - i am not sure why - i would agree that abslibre should contain only PKGBUILDs for packages which are available on the repos - but again they are harmless - none of those are in the default pacman.conf - AFAIK, they are only present in the git repo; so most people do not even know they exist

#4

Updated by bill-auger 7 months ago

java/byaccj appears to be a duplicate of pcr/byaccj

that would be a bug i suppose - something could be done about those without discussion

#5

Updated by gap 7 months ago

The same argument goes for virtually all other packages, eg. why not have a separate repo for emacs, one for radare2, one for $PKG, because in most cases people don't use it?

I thought the whole point was to have several large, coarsely-grained repos of general-purpose tools instead of many tiny repos people have to keep their configs up-to-date enabling and disabling as they come and go, which sounds like a pain.
If people want to install related packages in one go or see related packages in one organised place, isn't this the job of metapackages/package groups?

Moreover, the many tiny repos paradigm goes directly against our current repo policies on the wiki.

I think libre and pcr should stay separate because they have coarsely-grained purposes: liberated packages from Arch/Arch32/ArchARM/Artix and an assortment of packages which don't fit anywhere else, respectively.
Due to this, the Java packages and the personal repo packages (if they are not dead) could just as well go in pcr, and the kernels could just as well go in libre, or pcr, depending on whether we classify them technically as liberated packages or an assortment of packages which don't fit anywhere else.
unmaintained and retired are essentially named synonyms of "dead"/"deprecated" and don't seem to contain anything particularly useful.
In this way, we'd have 8 less repos to wrangle, and a dozen or so less packages to maintain or leave to rot.

#6

Updated by bill-auger 7 months ago

for completeness, there are a few more useless repos not
mentioned: (at least gnome-unstable, kde-unstable are presented
on the website) - they are probably abandoned arch repos

eg. why not have a separate repo for emacs, one for radare2, one for $PKG, because in most cases people don't use it?

if emacs had 20+ packages associated it, that were all useless
without emacs, that would actually make sense - the java repo
is probably like that - i would not be surprised if all of those
packages exist only to support one java application

I thought the whole point was to have several large, coarsely-grained repos of general-purpose tools

yes i suppose it is - core,extra,community,libre are those repos
- OTOH, those java package are probably not general-purpose
they are special purpose - kernels, nonprism, and nonsystem are
also special purpose most people have no reason to be interested
in them - applications like emacs may be interesting to a wide
audience (anyone who edits text files) - im not even sure what
the purpose of the java repo is (im looking at you, lukeshu) -
probably all of those packages could be deleted, rather than,
merging them - they all appear to have been put there by lukeshu
they may have been a work in progress, and never had a
completed purpose

If people want to install related packages in one go or see related packages in one organised place, isn't this the job of metapackages/package groups?

no those are to install many packages with a single command -
the packages need not be in the same repo

Moreover, the many tiny repos paradigm goes directly against our current repo policies on the wiki.

im not sure what you mean by that - off-hand, i would not
consider anything on the wiki to be policy - more like
explanations for how things happen to be, whether by convention,
habit, or legacy accident - in othe4r words, the wiki can be
changed to fit the reality, easier than the reality can be
changed to fit the wiki

I think libre and pcr should stay separate because they have coarsely-grained purposes: liberated packages from Arch/Arch32/ArchARM/Artix and an assortment of packages which don't fit anywhere else, respectively.

that is exactly my point - packages in PCR don't fit anywhere
else - the personal repos are for packages that should not be in
the main repos - they only fit "not in the main repos"

libre has more than only liberated packages - i wish that
it was only for blacklist replacement; but there is other stiff
in there too - i would like to split those out into a new repo

kernels fit well in a "kernels" repo - there once was
many more kernels - now that there are many fewer, i too
suggested removing the kernels repo; but megver did not want to
- that did not bother me - there is no practical benefit - most
people will never need to wrangle any of those - they can be
safely ignored - most people do not even know they exist - but
if people have a reason to modify pacman.conf, the octopi tool
makes it very simple to do

#7

Updated by gap 7 months ago

https://wiki.parabola.nu/Repositories does not even mention any of these small repos, which means making them is not policy, or the wiki is outdated.
I'd prefer the former.

My point is that if we actually applied the many tiny repos separated by narrow focus for specific tools paradigm, we'd end up with dozens of repos popping in and out of existence as packages come and go and we reorganise or shuffle packages around when we could just as well put them in a single large repo and carve out narrower groups of packages by assigning them to a package group/metapackage if that is convenient.

Sorting packages into tiny repos would be a massive waste of time, micro-managing what goes where, and there would inevitably be overlap and disputes over whether something should go somewhere, and confusion over where something actually is, especially for non-technical users being forced to use a separate tool just to enable and re-enable all these repos.

Other OS projects do this and it is an absolute nightmare trying to find something versus the way we already do it now, plus the organisation is confusing because of the overlap between categories.

There is no reason the kernels couldn't just go in the libre or pcr repo depending on how we technically classify them.
The kernels already fit there; making a new repo just for the kernels is artificial when they could just as well have gone there in the first place.
We are already a relatively small project and chopping up our repos into microscopic specks would be a waste of the resources we do have.

Also available in: Atom PDF