[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