[aur-general] Removal request: google-chrome-mini
This is not even funny: https://aur.archlinux.org/packages.php?ID=57611 - A clone of 'google-chrome-dev' - Otherwise the same but the build and dependencies somehow more 'minimal' - In practice completely useless Det
On Mar 16, 2012 8:49 PM, "Det" <nimetonmaili@gmail.com> wrote:
This is not even funny: https://aur.archlinux.org/packages.php?ID=57611 - A clone of 'google-chrome-dev' - Otherwise the same but the build and dependencies somehow more 'minimal' - In practice completely useless
Det
Package is the author's idea of KISS, saw a thread to that effect in the forums.
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? -- Sincerely, Alexander Rødseth Arch Linux Trusted User (xyproto on IRC, trontonic on AUR)
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 16 March 2012 20:55, Det <nimetonmaili@gmail.com> wrote:
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
I'll remove google-chrome-mini when the google-chrome-dev get's updated with the changes you mentioned. Lukas
On 18 March 2012 09:22, Lukáš Jirkovský <l.jirkovsky@gmail.com> 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 18 March 2012 09:23, Lukáš Jirkovský <l.jirkovsky at gmail.com> wrote:
On 18 March 2012 09:22, Lukáš Jirkovský <l.jirkovsky at gmail.com> 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.
It's done now. Here's the link to google-chrome-mini again: https://aur.archlinux.org/packages.php?ID=57611 Det
On 24 March 2012 12:26, Det <nimetonmaili@gmail.com> 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 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
On 25 March 2012 01:32, Det <nimetonmaili@gmail.com> 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
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 <nimetonmaili@gmail.com> 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 <daniel.wallace@gatech.edu>:
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 <nimetonmaili@gmail.com> 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 26/03/12 03:49, rafael ff1 wrote:
2012/3/25 Daniel Wallace <daniel.wallace@gatech.edu>:
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 <nimetonmaili@gmail.com> 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.
Deleted again. @tailinchu: For the reason mentioned by Det above, please do not re-upload this package.
On Mon, Mar 26, 2012 at 4:00 AM, Evangelos Foutras <evangelos@foutrelis.com> 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 <tailinchu@gmail.com> 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. :) )
and it's back https://aur.archlinux.org/packages.php?ID=57963 On Mon, Mar 26, 2012 at 05:51:10AM +0300, Evangelos Foutras wrote:
On Mon, Mar 26, 2012 at 4:00 AM, Evangelos Foutras <evangelos@foutrelis.com> 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 <tailinchu@gmail.com> 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...
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/
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" <b@bpiotrowski.pl> 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/
On Mon, Mar 26, 2012 at 12:14 PM, Taylor Lookabaugh <jesus.christ.i.love@gmail.com> wrote:
Have you tried emailing him personally?
Obviously, from the reply seen earlier in the thread.
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 <jesus.christ.i.love@gmail.com> wrote:
Have you tried emailing him personally?
Obviously, from the reply seen earlier in the thread.
On Mon, Mar 26, 2012 at 3:18 PM, Daniel Wallace <daniel.wallace@gatech.edu> wrote:
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.
I know I have no standing in AUR decision-making, but I find the uploader's 'logic' un-understandable. If his package is not necessary and changes nothing besides adding a dependency which already has 'provides=', how can he compare it with compile-flag-varying packages?
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
@ngoonee my point is that if a user can edit depends=, he could also as well edit build flags. @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. @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. 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. On Mon, Mar 26, 2012 at 3:03 PM, Det <nimetonmaili@gmail.com> wrote:
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
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)
@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 <rodseth@gmail.com> 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 26.3.2012 21:47, Tai-Lin Chu wrote:
@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.
google-chrome* packages are updated in an extraordinarily fast manner. Often within the first hour of the new release. If a package isn't being updated at all you should at first contact the maintainer. If you get no response, you should make an orphan request and start maintaining it yourself.
2. i want to have "no-gconf" explicitly. many users are not aware that they have to install no-gconf first, then install chrome.
Uh. They don't. See, I can be wrong too.
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.
Nooo, if _my_ logic applies (and it does, by the way), then we should just remove packages that don't have any meaningful changes in them. vlc-* and mplayer-* packages are _source_ packages. When they change the dependencies they actually change the features of the package coming out. It's a different story when this can be done any time you like anyway (eg. by installing no-gconf). And no, AUR isn't meant to be messy. Not a way in _hell_ would that make it more useful anyway. Finding what you like is gonna be _extremely_ hard if there's a zillion packages providing the same thing - all with their own silly little modifications. And how an earth would that help with keeping packages up-to-date? Is your solution for the maintenance system that we need to have 10 clones of every single package so that there's always gonna be an up-to-date one to choose from? Because filling up the AUR with "updated" packages just creates more problems than it resolves. If there's a redundant package in the AUR, then say it so it can be removed. Don't just join the fight against the system we already know isn't perfect. Det
Am Mon, 26 Mar 2012 18:47:11 +0000 schrieb Tai-Lin Chu <tailinchu@gmail.com>:
@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
@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 <tailinchu@gmail.com>: 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 <rodseth@gmail.com> 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)
thanks everyone for letting me know these. 2012/3/27 郑文辉(Techlive Zheng) <techlivezheng@gmail.com>:
@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 <tailinchu@gmail.com>: 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 <rodseth@gmail.com> 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)
Just wanted to make a correction to my explanation above, I meant "disown" a few places where I wrote "delete". Oh well, the point is still the same. :) @Tai-Lin Chu The system is not perfect, but AUR works quite well for its purpose. New software is almost always available, useful packages are made visible by the rating system and if nothing else, it's a great testing ground for packages that can later be moved to the official repositories. - Alexander
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).
On 03/27/2012 11:53 AM, Stefan Mark wrote:
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).
Yeah it does: └┌(%:~/Desktop/nvidia-beta-all)┌- ldd /opt/google/chrome/chrome | grep gconf libgconf-2.so.4 => /usr/lib/libgconf-2.so.4 (0x00007fcbbbd45000) But true, some applications do break when they can't use gconf: └┌(%:~/Desktop/nvidia-beta-all)┌- gucharmap gucharmap: symbol lookup error: gucharmap: undefined symbol: gconf_client_get_default Det
participants (14)
-
Alexander Rødseth
-
Allan McRae
-
Bartłomiej Piotrowski
-
Daniel Wallace
-
Det
-
Evangelos Foutras
-
Heiko Baums
-
Lukáš Jirkovský
-
Oon-Ee Ng
-
rafael ff1
-
Stefan Mark
-
Tai-Lin Chu
-
Taylor Lookabaugh
-
郑文辉(Techlive Zheng)