[aur-general] AUR cleanup policy
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.
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. .odp is a Libre-/OpenOffice file extension btw. Regards, Xyne
On Wed, Jun 19, 2013 at 8:57 PM, Xyne <xyne@archlinux.ca> 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.
.odp is a Libre-/OpenOffice file extension btw.
I know, I didn't expect it tow work, but I have no idea what kind of presentations are they talking about.
Regards, Xyne
On 19/06/13 12:53 PM, Karol Blazewicz wrote:
On Wed, Jun 19, 2013 at 8:57 PM, Xyne <xyne@archlinux.ca> 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.
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. On 19 June 2013 22:49, Connor Behan <connor.behan@gmail.com> wrote:
On 19/06/13 12:53 PM, Karol Blazewicz wrote:
On Wed, Jun 19, 2013 at 8:57 PM, Xyne <xyne@archlinux.ca> 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 Wed, Jun 19, 2013 at 11:44 PM, Karol Woźniak <wozniakk@gmail.com> 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.
On 19 June 2013 23:48, Karol Blazewicz <karol.blazewicz@gmail.com> wrote:
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.
We have a different definitions of "dead upstream" then :). I consider it dead when people are gone, not necessarily taking their past work with them.
BTW, please don't top-post.
Dah, damn gmail caught me into this again. Sorry. -- Pozdrawiam, Karol Woźniak aka Kenji Takahashi @ kenji.sx "Don't shoot the messenger."
----------------------------------------
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 <connor.behan@gmail.com> wrote:
On 19/06/13 12:53 PM, Karol Blazewicz wrote:
On Wed, Jun 19, 2013 at 8:57 PM, Xyne <xyne@archlinux.ca> 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 19 June 2013 23:49, Doug Newgard <scimmia22@outlook.com> 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 :). -- 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 <wozniakk@gmail.com> wrote:
On 19 June 2013 23:49, Doug Newgard <scimmia22@outlook.com> 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."
The search returns a dozen unmaintained packages and you have to look through them [...] I prefer to have a reasonable signal-to-noise ratio.
This could be solved by having search results list "stale" packages last (and/or greyed-out or something). "stale" could be defined as "is unmaintained and has not been updated in 6 months", so it could be automatically derived without introducing an extra flag..
participants (6)
-
Connor Behan
-
Doug Newgard
-
Karol Blazewicz
-
Karol Woźniak
-
Sam S.
-
Xyne