FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux User Repository

 
 
LinkBack Thread Tools
 
Old 03-26-2012, 10:25 AM
Oon-Ee Ng
 
Default Removal request: google-chrome-mini

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?
 
Old 03-26-2012, 03:03 PM
Det
 
Default Removal request: google-chrome-mini

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
 
Old 03-26-2012, 05:27 PM
Tai-Lin Chu
 
Default Removal request: google-chrome-mini

@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
 
Old 03-26-2012, 05:58 PM
Det
 
Default Removal request: google-chrome-mini

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=d73ff6beb888f8b2f45e19cd2a0deb9b0b8ca60 e



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
 
Old 03-26-2012, 06:01 PM
Alexander Rødseth
 
Default Removal request: google-chrome-mini

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)
 
Old 03-26-2012, 06:47 PM
Tai-Lin Chu
 
Default Removal request: google-chrome-mini

@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)
 
Old 03-26-2012, 08:47 PM
Det
 
Default Removal request: google-chrome-mini

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
 
Old 03-26-2012, 10:03 PM
Heiko Baums
 
Default Removal request: google-chrome-mini

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
 
Old 03-27-2012, 02:49 AM
Tai-Lin Chu
 
Default Removal request: google-chrome-mini

thanks everyone for letting me know these.

2012/3/27 郑文辉(Techlive Zheng) <techlivezheng@gmail.com>:
> 2012/3/27 Tai-Lin Chu <tailinchu@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
> 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)
 
Old 03-27-2012, 07:22 AM
Alexander Rødseth
 
Default Removal request: google-chrome-mini

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
 

Thread Tools




All times are GMT. The time now is 01:37 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org