I'm glad the patch looks fine, though I'm not sure I understand the issue about dependencies?

Well, AUR packages can depend on other AUR packages. If an AUR package is renamed which is itself a dependency, packages that depend on the old package name will be broken. On Wed, Jun 1, 2011 at 3:00 PM, Daenyth Blank wrote:

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.

That also seems to be valid for the dependencies=() array in depending PKGBUILDs. I suggest allowing renaming a package and marking it as out of date at the same time to have the PKGBUILD updated. Also all packages that depend on the renamed package should be marked out of date with an automatic comment that the dependency was renamed. regards mar77i

On Wed, Jun 1, 2011 at 3:13 PM, D. Can Celasun wrote:

...

This seems reasonable. One question: What user should the automatic comment belong to? Is there something like a pseudo user?

The best choice would be the maintainer of the package that is being renamed. It's also the guy to be held responsible for such a request. Other than that -1 on "parsing every PKGBUILD that has the package in deps/makedeps and updating them" because it will cause automagic breakage. regards mar77i

On Wed, Jun 01, 2011 at 04:13:09PM +0300, D. Can Celasun wrote:

On Wed, Jun 1, 2011 at 4:06 PM, Martti Kühne wrote:

...

...

I'm glad the patch looks fine, though I'm not sure I understand the issue about dependencies?

Well, AUR packages can depend on other AUR packages. If an AUR package is renamed which is itself a dependency, packages that depend on the old package name will be broken.

I assumed package deps are stored as package IDs (the proper way) not names, but I've checked the db and you are right.

There are a lot of dependencies that do not exist in the AUR (dependencies that reside in the binary repos and probably a few ones that do not exist anywhere at all). We used to use package IDs and a dummy package concept to fix this but just storing package names is way better. See also [1].

...

On Wed, Jun 1, 2011 at 3:00 PM, Daenyth Blank wrote:

...

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.

That also seems to be valid for the dependencies=() array in depending PKGBUILDs. I suggest allowing renaming a package and marking it as out of date at the same time to have the PKGBUILD updated. Also all packages that depend on the renamed package should be marked out of date with an automatic comment that the dependency was renamed.

This seems reasonable. One question: What user should the automatic comment belong to? Is there something like a pseudo user?

An alternative would be parsing every PKGBUILD that has the package in deps/makedeps and updating them, but that would mean altering packages without the knowledge/consent of the maintainer.

If no one has a better suggestion, I'll implement Martti's idea and re-submit the patch.

Automatic notification on dependency breakage has been discussed on aur-dev before [2] (well, sort of :p )... Still not sure if we're gonna implement this. I'd like to avoid making the AUR send out alerts for various stuff. [1] http://projects.archlinux.org/aur.git/commit/?id=7c91c592 [2] http://mailman.archlinux.org/pipermail/aur-dev/2011-March/001459.html

On Wed, Jun 1, 2011 at 7:54 PM, Lukas Fleischer wrote:

On Wed, Jun 01, 2011 at 04:13:09PM +0300, D. Can Celasun wrote:

...

On Wed, Jun 1, 2011 at 4:06 PM, Martti Kühne wrote:

...

...

I'm glad the patch looks fine, though I'm not sure I understand the issue about dependencies?

Well, AUR packages can depend on other AUR packages. If an AUR package is renamed which is itself a dependency, packages that depend on the old package name will be broken.

I assumed package deps are stored as package IDs (the proper way) not names, but I've checked the db and you are right.

There are a lot of dependencies that do not exist in the AUR (dependencies that reside in the binary repos and probably a few ones that do not exist anywhere at all). We used to use package IDs and a dummy package concept to fix this but just storing package names is way better. See also [1].

I see your point. I guess it makes sense.

...

...

On Wed, Jun 1, 2011 at 3:00 PM, Daenyth Blank < daenyth+arch@gmail.com> wrote:

...

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.

That also seems to be valid for the dependencies=() array in depending PKGBUILDs. I suggest allowing renaming a package and marking it as out of date at the same time to have the PKGBUILD updated. Also all packages that depend on the renamed package should be marked out of date with an automatic comment that the dependency was renamed.

This seems reasonable. One question: What user should the automatic comment belong to? Is there something like a pseudo user?

An alternative would be parsing every PKGBUILD that has the package in deps/makedeps and updating them, but that would mean altering packages without the knowledge/consent of the maintainer.

If no one has a better suggestion, I'll implement Martti's idea and re-submit the patch.

Automatic notification on dependency breakage has been discussed on aur-dev before [2] (well, sort of :p )... Still not sure if we're gonna implement this. I'd like to avoid making the AUR send out alerts for various stuff.

Discussed? As in a single patch with no comments? :) Anyway, I think that patch has a good idea behind it and maybe I can implement such an alert under this. I'm also against sending lots of unneeded alerts (we all remember the "I'm a robot" comments) but I think this is one of those places that it is justified.

[1] http://projects.archlinux.org/aur.git/commit/?id=7c91c592 [2] http://mailman.archlinux.org/pipermail/aur-dev/2011-March/001459.html

To everyone saying asking for action from maintainers is a bad idea: We'd be asking to simply rename a dependency in their PKGUBILDs. Is that really that much work?

On Wed, Jun 1, 2011 at 05:32, Alexander Rødseth 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.

On 1 June 2011 16:04, D. Can Celasun wrote:

On Wed, Jun 1, 2011 at 4:00 PM, Daenyth Blank wrote:

...

On Wed, Jun 1, 2011 at 05:32, Alexander Rødseth 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.

On 1 June 2011 17:03, D. Can Celasun wrote:

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

The main advantage is that the new package gets uploaded before the name change, meaning there won't be a mismatch between pkgname in the PKGBUILD and the name displayed on the web interface. It's just a more consistent way to handle renames. However, both approaches seem acceptable to me. :)

On Wed, Jun 1, 2011 at 5:27 PM, Evangelos Foutras wrote:

On 1 June 2011 17:23, Evangelos Foutras wrote:

...

On 1 June 2011 17:03, D. Can Celasun wrote:

...

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

The main advantage is that the new package gets uploaded before the name change, meaning there won't be a mismatch between pkgname in the PKGBUILD and the name displayed on the web interface. It's just a more consistent way to handle renames.

One more use case covered by the comment/vote transfer is when there are two very similar packages, both with votes and comments, and we decide to remove one but keep the other. We could optionally move the votes and comments from the package being removed to the remaining package.

Votes, sure. But merging comments is a very bad idea. Comments would be left without any context and it would only confuse people. Anyway, implementing the original way is easier (and I have limited time), so I'll do that first and maybe I'll work on the rest later.

2011/6/1 Lukáš Jirkovský

...

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

?

...

With this approach it is much easier to implement a transition period when the other packages can update their dependencies. Assume that the package foo is to be renamed to bar, but the package baz depends on foo. Maintainer of foo can upload a new package bar and notify the maintainer of baz to update the dependency. When the depends array in baz is corrected to refer bar instead of foo, the package foo can be deleted and its votes transfered to bar.

If the the rename is done in place this would not be possible. Therefore I support Evangelos' idea rather than in place rename.

Lukas

Actually, it is still possible. Here's how it'd work: - TU changes package name from foo to bar. - This automatically triggers an out-of-date notification (and an explanation comment) for all packages that depend on foo. - Everyone updates their packages to reflect the changes. Now all votes, comments and even notification lists are preserved without doing a single database query. I really don't think it gets more KISS than that.

On Wed, Jun 1, 2011 at 6:36 PM, Jakob Gruber wrote:

On 06/01/2011 05:26 PM, D. Can Celasun wrote:

...

Actually, it is still possible. Here's how it'd work:

- TU changes package name from foo to bar. - This automatically triggers an out-of-date notification (and an explanation comment) for all packages that depend on foo. - Everyone updates their packages to reflect the changes.

Now all votes, comments and even notification lists are preserved without doing a single database query. I really don't think it gets more KISS than that.

I beg to differ. The way it is right now is way more KISS. So far, my favorite suggestion is either 1) creating a way to transfer votes and comments or 2) keeping everything as it is.

Let's just agree to disagree :) Anyway, I plan on implementing the original idea, and I'll post the patch here. If whoever-in-charge-of-AUR considers it useful, it gets merged. Otherwise, people are free to implement their own solutions.

On Wed, Jun 1, 2011 at 7:48 PM, Ray Rashif wrote:

...

On 06/01/2011 05:26 PM, D. Can Celasun wrote:

...

Actually, it is still possible. Here's how it'd work:

- TU changes package name from foo to bar. - This automatically triggers an out-of-date notification (and an explanation comment) for all packages that depend on foo. - Everyone updates their packages to reflect the changes.

Now all votes, comments and even notification lists are preserved

without

...

doing a single database query. I really don't think it gets more KISS

On 1 June 2011 23:36, Jakob Gruber wrote: than

...

...

that.

I beg to differ. The way it is right now is way more KISS. So far, my favorite suggestion is either 1) creating a way to transfer votes and comments or 2) keeping everything as it is.

How about marking a checkbox upon upload where it would present a text box to rename from an older package to the current one?

x Rename package from |________________|

If this from field MATCHES the pkgname being submitted then as usual nothing would be done (submission as usual as if nothing had been marked; package would be created if it does not exist).

If it does NOT MATCH, then a rename function (such as the one this patch demonstrates) would be applied to that older pkg and then the submission continues. Of course, the older package must be owned by the currently logged in user. If the older pkg entered does not exist in the db then the submission fails. If a package gets wrongly renamed then the user can go through the same steps to rename that. No TU involvement here.

-- GPG/PGP ID: 8AADBB10

I think package name modification without TU involvement is a bad idea. There is a reason only TUs can delete a package and I think this functionality should also be considered as such.

On Wed, Jun 1, 2011 at 8:01 PM, Alexander Rødseth wrote:

I think renaming a package should be slightly cumbersome, and not that easy. Just one rename has the potential to create work for dozens of package maintainers because of dependency issues. Let's say that maintainers has to upload 10 updated packages per rename, and that there are 10 renames a day, it would be quite a bit of overall extra work, with some breakage and no clear win, except more total consistency of the system as a whole. (Of course, these are made-up numbers and may not be accurate...).

I believe those numbers are highly unrealistic. The package renaming thing would only be used under special circumstances (like the upcoming kernel26 name change) and it wouldn't take any significant effort to handle. Even if it did, such circumstances are quite rare (Linux 2.6 was released 8 years ago) and it would be worth the trouble.

On Wed, Jun 1, 2011 at 8:20 PM, Lukas Fleischer wrote:

On Wed, Jun 01, 2011 at 04:47:16PM +0300, Evangelos Foutras wrote:

...

On 1 June 2011 16:04, D. Can Celasun wrote:

...

On Wed, Jun 1, 2011 at 4:00 PM, Daenyth Blank

...

On Wed, Jun 1, 2011 at 05:32, Alexander Rødseth 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.

+1. If this will ever be implemented, it'll probably work that way. Merging comments and/or votes is the KISS approach here. Further implementation details should be discussed on aur-dev, please.

All right, I cave in. I'll implement it as such and send a patch to aur-dev.