[aur-general] Packages in Community and votes.

[Loui Chang]

On Mon, Nov 10, 2008 at 06:47:32PM +0100, Angel Velásquez wrote:
> On Mon, Nov 10, 2008 at 6:21 PM, Aaron Griffin <aaronmgriffin at gmail.com> wrote:
> > On Mon, Nov 10, 2008 at 10:31 AM, w9ya <w9ya at qrparci.net> wrote:
> >> 1 - I maintain an offshoot version of archlinux, derived from faunos, called
> >> "shackstick". It is used and is becoming quite popular amongst the ham radio
> >> community. It is packaged as a whole and the user does NOT download packages
> >> or even is part of the arch linux community, so NO votes are taken. Yet it
> >> uses over 25 of my packages that would seem to otherwise be without votes.
> >
> > Just to point out a flaw here. Users of these packages are not
> > ArchLinux users. They are shackstick users. So votes don't make sense
> > for ArchLinux. These packages would not make sense in an ArchLinux
> > repo, on an ArchLinux server, for use by 1 or 2 ArchLinux users, and a
> > few hundred users of another distribution. So, in the case you have
> > outlined, the voting is working perfectly as intended.
> >
> 
> The explain that bfinch shows is not the case, as I said (second time
> this day), there is an amount of packages (aspell,i18n related) which
> break the rule about "votes needed". I mean, maybe there is not
> chinesse support in Arch Linux, but why if we got a TU or Dev who
> speaks chinesse and he wants to move chinesse language packages to
> community?, he won't be able cause the packages aren't enough voted?
> this is very unfair, and that's why I think votes isn't the unique
> point to focus when a package is moved to community. I understand the
> fact about moving -non-popular or unuseful- packages to community and
> waste resources, is bad, and I know that exists hundres of packages
> without votes, IMHO the correct way to handle this is simply, the TU
> who add packages with very few votes should give a good reason about
> why he did it, and in case other TUs aren't agree the TU who upload
> the package should find better reasons, and try later. And again
> *language packages break the rule* simply.
> 
> Thanks

Yeah I agree there should be room for some exceptions. Dependencies
would be the obvious exceptions, and maybe perhaps i18n packages should
be included as well (optdepends?).