On Mar 16, 2012 14:55, "Alexander Rødseth" <rodseth at gmail.com> wrote:

Hi,

The current maintainer, taylorchu, replied:

...

1. it uses no gconf, so you dont need gtk3. 2. it does not try to move and symlink. it is vanilla as provided by google.

Do you still request the package to be deleted?

Well, the symlinks can be removed as they are unnecessary nowadays (the man page and the .desktop _should_ still be installed), while 'no-gconf' could just as well be manually installed from the AUR beforehand, as it replaces 'gconf'. Building 'openssl098' is the only thing that might bother some people. It could be moved to optional dependencies, since not everybody uses the built-in Pepper Flash anyway (which requires it). At the _very least_, if this package was to be kept in the AUR (which I disagree with) the name should be changed to something like 'google-chrome-dev-no-gconf'. But using the same logic every single package in the AUR depending on 'gconf' could be cloned with '-no-gconf' alternatives. Is _this_ what we want? Det

On 18 March 2012 09:22, Lukáš Jirkovský wrote:

I'll remove google-chrome-mini when the google-chrome-dev get's updated with the changes you mentioned.

Lukas

BTW: it would be nice if someone pings me when it gets updated, I notoriously forget things.

On 24 March 2012 12:26, Det wrote:

It's done now.

Here's the link to google-chrome-mini again: https://aur.archlinux.org/packages.php?ID=57611

Det

Thanks Det, I've removed the google-chrome-mini. Lukas

On 25 March 2012 01:32, Det wrote:

The maintainer doesn't seem to get the message. He re-uploaded it as "google-chrome-no-gconf", even though I already explained the user can just install "no-gconf" beforehand: https://aur.archlinux.org/packages.php?ID=57899

           Det

It seems someone already removed it. Thanks for the notice. LUkas

2012/3/25 Daniel Wallace :

not sure if this is the same guy, but https://aur.archlinux.org/packages.php?ID=57961 I just saw this pop up in the new packages On Sun, Mar 25, 2012 at 10:32:56AM +0200, Lukáš Jirkovský wrote:

...

On 25 March 2012 01:32, Det wrote:

...

The maintainer doesn't seem to get the message. He re-uploaded it as "google-chrome-no-gconf", even though I already explained the user can just install "no-gconf" beforehand: https://aur.archlinux.org/packages.php?ID=57899

           Det

It seems someone already removed it. Thanks for the notice.

LUkas

Yes, it is the very same guy. Now, this is getting funny.

On Mon, Mar 26, 2012 at 4:00 AM, Evangelos Foutras wrote:

@tailinchu: For the reason mentioned by Det above, please do not re-upload this package.

tailinchu, I'm going to quote your email to me below. However, if you would register on the list you would be able to reply directly to the list. (That would make things easier to follow.)

On Mon, Mar 26, 2012 at 5:02> AM, Tai-Lin Chu wrote:

...

i dont understand why he is really obsessed about this. he could simply ignore this package if he chooses to. he could have his own reason, but i have mine too.

We try to keep the AUR from becoming too confusing. One way this can be done is by discouraging the creation of very similar packages and/or removing obsolete packages. Det is suggesting that you can have a gconf-free system by installing the no-gconf package (also maintained by you). Therefore, *-no-gconf packages are redundant. Saying that you have a reason to upload this package without being more specific isn't enough, considering the package has been deleted 3 times already. (Please try to respond to the list, so I don't act as a messenger. :) )

On 26/03/12 13:36, Daniel Wallace wrote:

and it's back https://aur.archlinux.org/packages.php?ID=57963

And anyone who downloads source files using wget within the build() function needs to be taken out the back and shot...

Have you tried emailing him personally? Sent from my Samsung Stratosphere SCH-I405 Verizon 4G LTE. On Mar 25, 2012 9:13 PM, "Bartłomiej Piotrowski" wrote:

On 03/26/2012 05:36 AM, Daniel Wallace wrote:

...

and it's back https://aur.archlinux.org/packages.php?ID=57963

Removed again, but he'll reupload it again and again. Ban?

-- Bartłomiej Piotrowski Arch Linux Trusted User http://archlinux.org/

this is the email I just got On Sun, Mar 25, 2012 at 10:55:16PM -0700, Tai-Lin Chu wrote:

i really dont think removing a pkgbuild just because they are similar is a good idea, given that we have tons of similar PKGBUILD. if we do this, please do the same thing for these families: 1. chromium 2. vlc 3. mplayer 4. ... you will see that aur is supposed to be free. anyone should be able to upload pkgbuild.

On Mon, Mar 26, 2012 at 03:13:45PM +0800, Oon-Ee Ng wrote:

On Mon, Mar 26, 2012 at 12:14 PM, Taylor Lookabaugh wrote:

...

Have you tried emailing him personally?

Obviously, from the reply seen earlier in the thread.

Just came here to say I had a good laugh from all this. But the thing is that if we banned this guy all his other 12 packages[1] would need new maintainers (they don't seem to be anything special, though. His most voted package with 17 votes (no-gconf[2]) doesn't even require maintenance). [1] = https://aur.archlinux.org/packages.php?K=taylorchu&SeB=m [2] = https://aur.archlinux.org/packages.php?ID=36554 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

@Alexander Rødseth that's "how it should work", but unfortunately none of these work well in reality. my reason of cloning is that "the time when these packages will update or fit your need is known". god knows when these packages will update; it could be weeks or months(or never). i either have to keep my own version of pkgbuild or change the pkgbuild every time i install. that's not efficient. @Det 1. i dont think my pkgbuild has any wrong dependency. i am really concerned about dependency, and carefully checked chromium build script. 2. i want to have "no-gconf" explicitly. many users are not aware that they have to install no-gconf first, then install chrome. 3. as i said, aur is meant to a mess if you want it to be actually useful. if your logic applies, then we should remove all "mplayer-*", "vlc-*" ..., because we already have mplayer, vlc in [extra]. these "families" of packages are just adding or removing some flags and dependencies(some are even incorrect). having "mutations" gives convenience for users. users dont care about mess really; they care about time as they dont want to manually edit pkgbuild. On Mon, Mar 26, 2012 at 6:01 PM, Alexander Rødseth wrote:

Hi,

"out-of-date for a long time" is handled by flagging packages, e-mailing the maintainer, waiting and then requesting the package to be deleted here, then it's deleted by TUs "does not compile" is handled by commenting or contacting the maintainer then possibly requesting the package to be deleted here, then it's deleted by TUs "orphaned for years" is handled by adopting and fixing the package, by requesting the package to be deleted here or by random TUs "has dead upstream" is handled by commenting or contacting the maintainer then possibly requesting the package to be deleted here, then it's deleted by TUs "duplicate package" is handled by requesting the package to be deleted here or by random TUs

TUs handle cases as they appear on the mailing list, as they stumble over problematic packages by them selves or in connection with the AUR cleanup day (https://wiki.archlinux.org/index.php/AUR_Cleanup_Day).

Your case is "duplicate package" and is handled as such. The other cases are handled without needing to direct effort from "duplicate package" cases.

-- Best regards,  Alexander Rødseth  Arch Linux Trusted User  (xyproto on IRC, trontonic on AUR)

Am Mon, 26 Mar 2012 18:47:11 +0000 schrieb Tai-Lin Chu :

@Alexander Rødseth that's "how it should work", but unfortunately none of these work well in reality.

That's how it does work in reality. If you find such a package which fits in one of the cases Alexander mentioned, do what Alexander explained. If a package is not maintained anymore, contact the maintainer, wait at least two weeks for a response, and if you don't get a response, send an orphan request to this mailing list. It usually takes only a few minutes until a TU orphans this package, so that you can adopt it. No need for a duplicate package. If you find a duplicate package or a package which has a dead upstream, send a removal request to this mailing list. If upstream is really dead and the package can't be built or used anymore as it is, it usually takes only a few minutes until a TU removes this package.

my reason of cloning is that "the time when these packages will update or fit your need is known". god knows when these packages will update; it could be weeks or months(or never). i either have to keep my own version of pkgbuild or change the pkgbuild every time i install. that's not efficient.

As explained above and by Alexander, contact the maintainer and ask him to update or orphan the package. If you don't get a response after two weeks, ask here on this mailing list to have the package orphaned. Then adopt it and maintain it yourself. No need for uploading a duplicate package.

2. i want to have "no-gconf" explicitly. many users are not aware that they have to install no-gconf first, then install chrome.

1. Write a Wiki page about (no-)gconf if it doesn't exist already. If one exists, edit it and explain this. 2. Write an AUR comment to your no-gconf package which explains that no-gconf has to be installed before the other packages, and that every package which shall not use gconf has to be reinstalled afterwards. 3. Write a post_install() message which explains the same.

3. as i said, aur is meant to a mess if you want it to be actually useful. if your logic applies, then we should remove all "mplayer-*", "vlc-*" ..., because we already have mplayer, vlc in [extra].

You compare apples to oranges.

these "families" of packages are just adding or removing some flags and dependencies(some are even incorrect). having "mutations" gives convenience for users. users dont care about mess really; they care about time as they dont want to manually edit pkgbuild.

Having multiple duplicate packages in AUR don't save time, it's a waste of time, because the users are confused and don't know anymore which of these packages is the best to have installed. If I recall correctly there was such an issue with a lot of flashplugin packages e.g. Once they have been tidied up. There was quite a long discussion about this here on this mailing lists in which several people checked every single package and their differences. Finding such differences and finding out that there are so many duplicate packages is also a waste of time. And the server space is wasted by duplicate packages, too. Heiko

thanks everyone for letting me know these. 2012/3/27 郑文辉(Techlive Zheng) :

...

@Alexander Rødseth that's "how it should work", but unfortunately none of these work well in reality. my reason of cloning is that "the time when these packages will update or fit your need is known". god knows when these packages will update; it could be weeks or months(or never). i either have to keep my own version of pkgbuild or change the pkgbuild every time i install. that's not efficient.

@Det 1. i dont think my pkgbuild has any wrong dependency. i am really concerned about dependency, and carefully checked chromium build script.

2. i want to have "no-gconf" explicitly. many users are not aware that they have to install no-gconf first, then install chrome.

3. as i said, aur is meant to a mess if you want it to be actually useful. if your logic applies, then we should remove all "mplayer-*", "vlc-*" ..., because we already have mplayer, vlc in [extra]. these "families" of packages are just adding or removing some flags and dependencies(some are even incorrect). having "mutations" gives convenience for users. users dont care about mess really; they care about time as they dont want to manually edit pkgbuild. No, no, I do care the the mess of the AUR.Sometimes to choose between several similar packages is a pain, you have to download all of them and enven compile them to know it.But if there is only one, even if it was broken, then you can download it, trying to fix it, then post your fix to the comments to let the maintainer and other users know. If the

2012/3/27 Tai-Lin Chu : maintainer does not response and then you really care about the package, then you can request here to adopt it after two weeks instead of create you own version in AUR with a different name.This is the How Arch Linux Communnity works and how it grows to today.Even if you just care about your own need, you can maintain you own PKGBUILD repo, please do not pollute the public.The AUR is not to be messed.Think about it, you create a duplicated package, you get satisfied with it, but after a while, someone got come up and clean up you mess again like this time.

Arch Linux is not a linux distro mean to keep the user lazy and foolish, the user need to get familiar with the pain the AUR PKGBUILD bring, and learn it fix it, this is a growing up process.Making AUR mess with lots of duplicated packages could not save the users time if he has skills to fix something, it waste his time to make decision and to send mail here to get duplicated deleted.

Arch Linux is created by people who want to make life simple and tidy and clean, not this kind of AUR messy could be accepted.

Democracy is slow and no efficient, but it is the way to keep every going longer, right?This is the thing we Chinese need to learn.

...

On Mon, Mar 26, 2012 at 6:01 PM, Alexander Rødseth wrote:

...

Hi,

"out-of-date for a long time" is handled by flagging packages, e-mailing the maintainer, waiting and then requesting the package to be deleted here, then it's deleted by TUs "does not compile" is handled by commenting or contacting the maintainer then possibly requesting the package to be deleted here, then it's deleted by TUs "orphaned for years" is handled by adopting and fixing the package, by requesting the package to be deleted here or by random TUs "has dead upstream" is handled by commenting or contacting the maintainer then possibly requesting the package to be deleted here, then it's deleted by TUs "duplicate package" is handled by requesting the package to be deleted here or by random TUs

TUs handle cases as they appear on the mailing list, as they stumble over problematic packages by them selves or in connection with the AUR cleanup day (https://wiki.archlinux.org/index.php/AUR_Cleanup_Day).

Your case is "duplicate package" and is handled as such. The other cases are handled without needing to direct effort from "duplicate package" cases.

-- Best regards,  Alexander Rødseth  Arch Linux Trusted User  (xyproto on IRC, trontonic on AUR)

On 25.03.2012 01:32, Det wrote:

On 24 March 2012 13:41, Det <nimetonmaili at gmail.com> wrote:

...

Thanks Det, I've removed the google-chrome-mini.

Lukas

The maintainer doesn't seem to get the message. He re-uploaded it as "google-chrome-no-gconf", even though I already explained the user can just install "no-gconf" beforehand: https://aur.archlinux.org/packages.php?ID=57899

Det

Installing no-gconf will just replace gconf with nothing (doesnt that break every normal package that needs gconf?). People might want to have gconf, but also a chrome which does not use gconf (actually, i have an emacs package that does the same thing).