On Wed, Jun 1, 2011 at 4:47 PM, Evangelos Foutras <[email protected]>wrote:
> On 1 June 2011 16:04, D. Can Celasun <[email protected]> wrote: > > On Wed, Jun 1, 2011 at 4:00 PM, Daenyth Blank <[email protected] > >wrote: > > > >> On Wed, Jun 1, 2011 at 05:32, Alexander Rødseth <[email protected]> > 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).
