On 19/06/13 12:53 PM, Karol Blazewicz wrote:

On Wed, Jun 19, 2013 at 8:57 PM, Xyne wrote:

...

On 2013-06-18 13:48 +0200 Karol Blazewicz wrote:

...

What's the policy wrt to packages that have been submitted years ago and are neither developed upstream nor maintained in the AUR since then? Just let them be or get rid of them as they're of no use? If there're old unmaintained packages foo and foo-git, is it OK to request removing at least one of them? Which one?

https://aur.archlinux.org/packages/a4/ https://aur.archlinux.org/packages/a4-bzr/

The PKGBUILD need updating but it still builds and runs so I can pick it up, update and orphan it. I don't know which filetypes does it open (.odp is not recognized) and the editor doesn't work, so you can't create a new presentation from scratch. It's man page is of no help.

Packages should only be removed if they conflict with policy (copies of official repo packages, malware, illegal packages) or if upstream is dead. Even if the PKGBUILD is an ancient relic from the age of Judd in need of a complete rewrite, we tend to leave them as placeholders. AUR lacks 'mark package as broken' feature, I guess I can leave a comment that says it's broken + post compile errors etc. Maybe somebody will post a fix ...

With regard to dead upstream, do I have to Google around to see if they moved it somewhere or is it OK to lazily submit for deletion? I'm talking about orphaned packages w/o an updated PKGBUILD in the comments or at least a comment that says upstream moved to a different place.

I would only submit such packages for deletion if their PKGBUILDs do a simple ./configure && make && make install. If there are non-trivial patches, even if they are long broken, I would leave it in the AUR. When someone comes along and says "I want to make this dead package work again" patches that once work can be a useful starting point.

On Wed, Jun 19, 2013 at 11:44 PM, Karol Woźniak wrote:

I am against removing "dead upstream" packages, unless upstream is completely gone, i.e. there is no way to obtain necessary files. I am maintaining at least two packages with upstream long dead, but (after my patches, of course) they're still working and are used by some people.

How can I get the sources? If you provide a mirror, I think it's OK. When talking about ded upstream, I'm not talking about upstream website being 404, I'm talking about the sources for the package being gone. BTW, please don't top-post.

----------------------------------------

Date: Wed, 19 Jun 2013 23:44:44 +0200 From: wozniakk@gmail.com To: aur-general@archlinux.org Subject: Re: [aur-general] AUR cleanup policy

I am against removing "dead upstream" packages, unless upstream is completely gone, i.e. there is no way to obtain necessary files. I am maintaining at least two packages with upstream long dead, but (after my patches, of course) they're still working and are used by some people.

I don't think anyone's suggesting just removing them en mass, but removing them if upstream is gone, they don't build, and haven't been updated in a long time. In that situation, what would the reason be to keep them?

On 19 June 2013 22:49, Connor Behan wrote:

...

On 19/06/13 12:53 PM, Karol Blazewicz wrote:

...

On Wed, Jun 19, 2013 at 8:57 PM, Xyne wrote:

...

On 2013-06-18 13:48 +0200 Karol Blazewicz wrote:

...

What's the policy wrt to packages that have been submitted years ago and are neither developed upstream nor maintained in the AUR since then? Just let them be or get rid of them as they're of no use? If there're old unmaintained packages foo and foo-git, is it OK to request removing at least one of them? Which one?

https://aur.archlinux.org/packages/a4/ https://aur.archlinux.org/packages/a4-bzr/

The PKGBUILD need updating but it still builds and runs so I can pick it up, update and orphan it. I don't know which filetypes does it open (.odp is not recognized) and the editor doesn't work, so you can't create a new presentation from scratch. It's man page is of no help.

Packages should only be removed if they conflict with policy (copies of official repo packages, malware, illegal packages) or if upstream is dead. Even if the PKGBUILD is an ancient relic from the age of Judd in need of a complete rewrite, we tend to leave them as placeholders. AUR lacks 'mark package as broken' feature, I guess I can leave a comment that says it's broken + post compile errors etc. Maybe somebody will post a fix ...

With regard to dead upstream, do I have to Google around to see if they moved it somewhere or is it OK to lazily submit for deletion? I'm talking about orphaned packages w/o an updated PKGBUILD in the comments or at least a comment that says upstream moved to a different place.

I would only submit such packages for deletion if their PKGBUILDs do a simple ./configure && make && make install. If there are non-trivial patches, even if they are long broken, I would leave it in the AUR. When someone comes along and says "I want to make this dead package work again" patches that once work can be a useful starting point.

-- Pozdrawiam, Karol Woźniak aka Kenji Takahashi @ kenji.sx "Don't shoot the messenger."

On Thu, Jun 20, 2013 at 1:27 AM, Karol Woźniak wrote:

On 19 June 2013 23:49, Doug Newgard wrote:

...

----------------------------------------

I don't think anyone's suggesting just removing them en mass, but removing them if upstream is gone, they don't build, and haven't been updated in a long time. In that situation, what would the reason be to keep them?

For example there might be some patches already applied which could help a possible future maintainer to bring the package back to life. And even if not, someone might find an application he needs through our search and then adopt it. I sometimes do it myself, instead of googling around for something, I go straight to yaourt -Ss with some keywords :).

The search returns a dozen unmaintained packages and you have to look through them, check the PKGBUILDs for any bits that are still relevant, find where upstream has gone etc. Sometimes the first package will be what you need, other times none of them will fit. I don't want to remove valuable info, but I prefer to have a reasonable signal-to-noise ratio.

-- Pozdrawiam, Karol Woźniak aka Kenji Takahashi @ kenji.sx "Don't shoot the messenger."