[aur-general] Deletion request
Hello TUs, The next two packages are with the same application in AUR, I don't know which one is worth to delete, maybe I prefer lua-expat name to luaexpat. luaexpat: http://aur.archlinux.org/packages.php?ID=13509 lua-expat: http://aur.archlinux.org/packages.php?ID=21939 Best Regards, Laszlo Papp
Laszlo Papp wrote:
Hello TUs,
The next two packages are with the same application in AUR, I don't know which one is worth to delete, maybe I prefer lua-expat name to luaexpat.
Laszlo, I prefer the lua-expat name as well, but ... 1. luaexpat is the package under active maintenance. (lua-expat hasn't been updated since Dec 3, 2008). 2. luaexpat is required by all the prosody packages, whereas lua-expat is only required by lua-gtk. Since you maintain lua-gtk, could you please change the dependency from lua-expat to luaexpat? Once that is done, I'll go ahead and delete lua-expat. Regards, -- Chris
Chris Brannon wrote:
Laszlo Papp wrote:
Hello TUs,
The next two packages are with the same application in AUR, I don't know which one is worth to delete, maybe I prefer lua-expat name to luaexpat.
Laszlo, I prefer the lua-expat name as well, but ... 1. luaexpat is the package under active maintenance. (lua-expat hasn't been updated since Dec 3, 2008). 2. luaexpat is required by all the prosody packages, whereas lua-expat is only required by lua-gtk.
Since you maintain lua-gtk, could you please change the dependency from lua-expat to luaexpat? Once that is done, I'll go ahead and delete lua-expat.
Regards, -- Chris
General question: If someone were willing to follow through with it, would it be better to enforce the naming guidelines and modify the affected packages, or does it simply not matter? It seems unfortunate that "non-standard" names can get locked in this way. In this case, there are only 3 prosody packages between 2 maintainers. Regards, Xyne
Xyne wrote:
General question: If someone were willing to follow through with it, would it be better to enforce the naming guidelines and modify the affected packages, or does it simply not matter? It seems unfortunate that "non-standard" names can get locked in this way.
In this case, there are only 3 prosody packages between 2 maintainers.
In this specific case, the name luaexpat seems to be the correct one, although it is aesthetically unappealing. It is the name of the source tarball and the tree contained therein. Also, the project's URL uses that name (though the page is temporarily inaccessible). I think I made the right choice earlier. In the general case, if the package was named incorrectly, it is probably good to contact the maintainers of packages that depend on it. Regards, -- Chris
On Mon, Nov 9, 2009 at 7:29 AM, Chris Brannon <cmbrannon79@gmail.com> wrote:
Xyne wrote:
General question: If someone were willing to follow through with it, would it be better to enforce the naming guidelines and modify the affected packages, or does it simply not matter? It seems unfortunate that "non-standard" names can get locked in this way.
In this case, there are only 3 prosody packages between 2 maintainers.
In this specific case, the name luaexpat seems to be the correct one, although it is aesthetically unappealing. It is the name of the source tarball and the tree contained therein. Also, the project's URL uses that name (though the page is temporarily inaccessible). I think I made the right choice earlier.
In the general case, if the package was named incorrectly, it is probably good to contact the maintainers of packages that depend on it.
Regards, -- Chris
I agree with both of you here, I think in this special case Chris took good decision which one was to delete because the 'luaexpat' package that's the dependencies of more packages in AUR, but Xavier's right too in that regard so that it would be nice thinking of Packaging Standards extension (if it's not involved until now) with recommended/suggested package name in these situation Just see vim-*, php-*, emacs-*, xemacs-* from the extra/community repository as samples. I think the unity here too would be a good step. Best Regards, Laszlo Papp
On Sun, Nov 8, 2009 at 10:55 AM, Chris Brannon <cmbrannon79@gmail.com> wrote:
2. luaexpat is required by all the prosody packages, whereas lua-expat is only required by lua-gtk.
lua-expat : provides=(luaexpat)
On Tue, Nov 10, 2009 at 04:42, Xavier <shiningxc@gmail.com> wrote:
On Sun, Nov 8, 2009 at 10:55 AM, Chris Brannon <cmbrannon79@gmail.com> wrote:
2. luaexpat is required by all the prosody packages, whereas lua-expat is only required by lua-gtk.
lua-expat : provides=(luaexpat)
Does the AUR parse provides= when listing depends? Pacman can use that info *if it's in a repo*, but can the same be said for AUR?
On Tue 10 Nov 2009 08:12 -0500, Daenyth Blank wrote:
On Tue, Nov 10, 2009 at 04:42, Xavier <shiningxc@gmail.com> wrote:
On Sun, Nov 8, 2009 at 10:55 AM, Chris Brannon <cmbrannon79@gmail.com> wrote:
2. luaexpat is required by all the prosody packages, whereas lua-expat is only required by lua-gtk.
lua-expat : provides=(luaexpat)
Does the AUR parse provides= when listing depends? Pacman can use that info *if it's in a repo*, but can the same be said for AUR?
No, but that is something you should write when renaming a package. And I don't think we should keep badly named packages around. Change 'em and let the dependents catch up. This is 'unsupported' after all.
On Tue, Nov 10, 2009 at 3:26 PM, Loui Chang <louipc.ist@gmail.com> wrote:
On Tue 10 Nov 2009 08:12 -0500, Daenyth Blank wrote:
On Tue, Nov 10, 2009 at 04:42, Xavier <shiningxc@gmail.com> wrote:
On Sun, Nov 8, 2009 at 10:55 AM, Chris Brannon <cmbrannon79@gmail.com> wrote:
2. luaexpat is required by all the prosody packages, whereas lua-expat is only required by lua-gtk.
lua-expat : provides=(luaexpat)
Does the AUR parse provides= when listing depends? Pacman can use that info *if it's in a repo*, but can the same be said for AUR?
No, but that is something you should write when renaming a package. And I don't think we should keep badly named packages around. Change 'em and let the dependents catch up. This is 'unsupported' after all.
Maybe it's worth to extend here, to avoid bad package naming in the future. http://wiki.archlinux.org/index.php/Arch_Packaging_Standards#Package_Naming Best Regards, Laszlo Papp
participants (6)
-
Chris Brannon
-
Daenyth Blank
-
Laszlo Papp
-
Loui Chang
-
Xavier
-
Xyne