[aur-general] Removal request: google-chrome-mini

[Det]

On 26.3.2012 20:27, Tai-Lin Chu wrote:
> @ngoonee
> my point is that if a user can edit depends=, he could also as well
> edit build flags.
 From what I remember your dependency section was wrong anyway, so the 
user's not even supposed to edit that. In addition 'no-gconf' provides 
'gconf' so I don't understand why would anybody need a separate package 
to install it.

> @Det
> i dont think this is a good idea to ban users like this. someone mentioned that
> creating too many similar packages will create confusion. I dont think
> this applies to me.
> i already renamed the package to "google-chrome-no-gconf"; this is
> really clear and distinguishable
> from 3 other google-chrome packages.
Yes. It's distinguishable. The problem is that there's nothing to 
actually distinguish from. Your package doesn't even install the man 
page or the .desktop file. Just remove those, if they bother you so much.

> @everyone
> for people who read my last post, i just searched mplayer:
> mplayer-fribidi-pulse and mplayer-fribidi. you might think "why does
> these guys create  new pkgbuild while mplayer in extra has all these
> features?" the reason is that "he feels he needs to", and i think this
> is enough.
Those should be removed then. [extra]'s mplayer didn't use to support 
fribidi back when the two were uploaded: 
http://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/mplayer&id=d73ff6beb888f8b2f45e19cd2a0deb9b0b8ca60e

> btw, there are many pkgbuild that are "out-of-date for a long time",
> "does not compile", "orphaned  for years", or "has dead upstream". I
> think you should put effort on these packages. picking on the packages
> that are similar should be the last thing to work on.
Right. Would you imagine the mess your logic would create? Every single 
package in the AUR could be cloned with not only -no-gconf alternatives 
but just about any kind as long as there was just the tiniest difference 
from the original one (eg. the description included a dot (.)).

Also it's much harder to actually start building an uncompilable package 
and fix whatever is wrong with it than to just remove a redundant one. 
If there's a maintainer out there willing to do the work for us, then so 
be it. But we can't _know_ that, and _that's_ why so many packages exist 
in the AUR that don't even compile. Because nobody cares enough to make 
them.

                 Det