[arch-dev-public] Repo Distinctions

Damir Perisa damir.perisa at solnet.ch
Tue Oct 16 20:19:18 EDT 2007

Wednesday 17 October 2007, Paul Mattal wrote:
 | 3) Some good criteria for classifying packages in one repo or
 | another are:
 |    a) Desire to maintain a package long-term.
 |    b) Association with a particular group of people you trust.

well written! 

 | 4) There are many who actually do trust developers more than TUs.
 | This is not intended as a judgement, rather as an observation.
 | My feeling is that we should have under the developer umbrella a
 | split of the existing [extra] into two repos:
 | [main] 
 | [...]
 | [extra] 
 | [...] 
my first thought was: again another repo? 

my second thought was: again another repo! :)

with the [current]->[core] transition, we actually dumped a huge lot 
of pkgs to [extra] that are more than extra. they are main nodes in 
dependencies and essential to lots of software around (to take a wild 
example: libpng). 

extra had already a broad spectrum of pkgs inside. some falling in the 
same category mentioned above, others less essential but filling an 
otherwise big hole in arch. lets take an example: science/openbabel 
is a "niche" package, that is probably only to some use to people who 
work with molecule data. but for these people, it is kind of a tool 
they need like you need vim or gcc on your computer. linux is not 
only for developers of linux... it is broader. it got broader becuase 
of the great idea behind it. :)

libpng and openbabel are in extra. they are both needed to be 
maintained by devs. not because they are better than TUs, but because 
they are official and can be run after, if they miss something. they 
are not so easy to walk away and the pkg is maintained continuously.

the proposed [main] category, or lets say [mantle] (to be around the 
core - thinking geologically) would include all the pkgs that moved 
from [current] to [extra] in the first place and in addition will 
take some of the pkgs from [extra] to it. 

to a certain ammount i like the distinction - it clarifies things and 
actually should have been done while doing the current->core 
business ;) 
on the other hand, its again breaking backwards compatibility and 
making another ISO required. 

the question i am asking with this: can we live with an [extra] that 
holds also the mantle pkgs that are actually more than extra? or are 
we going to split extra into two repos?

i'm against moving pkgs from extra to community that are for a reason 
maintained by devs already, except there is reason not to keep them 
in extra. all the pkgs that seem like niche pkgs may require to be 
seen as official pkgs of a distro not to everybody but to a certain 
target group of users. there are some (from my point of view around 
6% of pkgs) pkgs in extra that may be removed or moved to community 
simply because the only reason they are in extra are historical 
(since earlier there was no such thing as community repos).  

about orphans: i'm against allowing any official pkg to stay orphan 
for a log time. besides the bad image we gain with this 
non-commitment to some pkgs it also is a risk to miss important 
updates and miss fixing things that should be done and that lots of 
users depend uppon.  ---- i'm however not for any overreaction here, 
since our web-interface is still missing the assignment of 
maintainence people for x86_64 as well as missing the multiple 
assignment of people to one single package. this lots of orphans will 
get reduced to a big ammount with making our web-interface more 
modern. then the next step would be to go through all (not yet 
removed orphans by repo cleanup) and multiple-assign them to people 
who either want to maintain them or have to, because they are 
dependences to pkgs they maintain (i like this idea - i assigned 
myself e.g. to imake since some of the pkgs i maintain depend on a 
working imake... to take an example).

to repeat the question i'm asking here:

can we live with an [extra] that holds also the mantle pkgs that are 
actually more than extra (that were in current)? or are we going to 
split extra into two repos?

- D

            °        °           °
             °      °            °
     ><((((º>      °              °
                    °            °
                   °            <º)))><

More information about the arch-dev-public mailing list