> Hello,
>
> since version 23, the Ruby mode is included in Emacs itself, therefore
> the package
> http://aur.archlinux.org/packages.php?ID=13483
> is no longer needed and can be deleted.
Deleted.
-- Chris
11-09-2009, 03:20 AM
Xyne
Deletion request
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.
> >
> > luaexpat:
> > http://aur.archlinux.org/packages.php?ID=13509
> >
> > lua-expat:
> > http://aur.archlinux.org/packages.php?ID=21939
>
> 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
11-09-2009, 05:29 AM
Chris Brannon
Deletion request
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
11-10-2009, 04:31 AM
Laszlo Papp
Deletion request
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
11-10-2009, 08:42 AM
Xavier
Deletion request
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)
11-10-2009, 12:12 PM
Daenyth Blank
Deletion request
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?
11-10-2009, 01:26 PM
Loui Chang
Deletion request
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.
11-10-2009, 07:59 PM
Laszlo Papp
Deletion request
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.
Deletion request
