[aur-general] [PATCH 1/1] TUs can change package names

[D. Can Celasun]

On Wed, Jun 1, 2011 at 4:47 PM, Evangelos Foutras <foutrelis at gmail.com>wrote:

> On 1 June 2011 16:04, D. Can Celasun <dcelasun at gmail.com> wrote:
> > On Wed, Jun 1, 2011 at 4:00 PM, Daenyth Blank <daenyth+arch at gmail.com
> >wrote:
> >
> >> On Wed, Jun 1, 2011 at 05:32, Alexander Rødseth <rodseth at gmail.com>
> wrote:
> >> > I like both the idea of it being possible to change the names of
> >> > packages and the patch.
> >> > But, what about dependencies? Should they be left dangling?
> >> >
> >> > - Alexander Rødseth
> >> >
> >>
> >> This patch leaves the pkgname in the PKGBUILD as the old name.
> >> Probably not an issue, but the maintainer would have to submit an
> >> updated PKGBUILD after the name change.
> >>
> >
> >
> > Yeah I thought about that, but when the package name goes from "foo" to
> > "bar", the maintainer might want to add replaces=("foo") etc. So it's
> > probably best to leave it up to the maintainer.
>
> An idea I wouldn't mind seeing implemented is the ability to transfer
> the votes and comments to another package when deleting the old
> package.
>
> For example, suppose the "foo" package gets a new name, say "bar".
>
> - Its maintainer uploads a new "bar" package with provides=('foo') and
> conflicts=('foo'). Then, they request the old package to be removed
> and at the same time mention the name of the new package.
> - A TU puts the name (or ID?) of the new package in a box next to the
> delete check box and proceeds to delete it. The votes and comments get
> reassigned to the new package.
>
> The above should work much better than any attempt to rename packages
> in place. We also avoid the issue that came up regarding the name
> mismatch in the PKGBUILD right after the package is renamed in the AUR
> database.
>


Possible, but is it really necessary? How is this different than the
original approach (TU changes the name, maintainer updates the PKGBUILD) ?

Unless I'm missing something, it would end up doing the same thing with
increased overhead (both in the code and the interface).