[aur-general] Removal request: google-chrome-mini

[Heiko Baums]

Am Mon, 26 Mar 2012 18:47:11 +0000
schrieb Tai-Lin Chu <tailinchu at 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