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