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
