[aur-general] Orphaning request - chromium-beta and clamav-devel

Heiko Baums lists at baums-on-web.de
Thu Sep 23 18:35:58 EDT 2010

Am Fri, 24 Sep 2010 05:54:51 +0800
schrieb Ray Rashif <schiv at archlinux.org>:

> That is _not_ the "definition" of "maintaining a package", it is
> "part" of the maintenance. Everyone has a life, and everyone has a
> choice. This is the bazaar.
> It is correct that rapid action is applauded, but it is not a
> requirement for ownership of a package. If anyone is unhappy with the
> frequency or time it takes for the owner to update her package(s), the
> concerned can either update the copy of the buildscripts locally and
> inform everyone else how to do it, or, request to orphan the package
> so she can help maintain instead and provide the rapid action which
> was previously lacking. Of course, that does not mean we would gladly
> comply with such a request.

But those requests should not be sent after 2 or 3 hours after an
upstream release. There's usually a reason why someone owns a package.
It's because he usually wants to maintain it. And there are sometimes
very good reasons (security issues, upstream bugs, building fails,
etc.) why the maintainer doesn't update the package within 2 or 3 hours
but several weeks later if at all.

And there are a lot of such impatient people out there who only see
that there's a new upstream version, then whine because the AUR package
is not updated, and don't see, and don't want to know the reasons why
the package is not updated yet.

So it's absolutely necessary to first contact the maintainer to see, if
he is still active and still interested in this package. Only if he
doesn't respond, an orphan request should be sent to the mailing list.

And such an ownership gives also some consistency. Well, there are
packages in whose PKGBUILD only $pkgver needs to be incremented. But
there are also packages which take some more work to maintain it, where
Arch specific scripts need to be written, build configurations have to
be modified or the build system is quite fragile. And if such packages
would permanently orphaned and adopted and again orphaned, and updated
by people who aren't familiar with these packages, you'll get most
likely serious problems every now and then. So it's better to have those
packages owned and maintained by only one person, who is familiar with
these packages, and to be a bit patient until the package is updated.


More information about the aur-general mailing list