[aur-general] [PATCH 1/1] TUs can change package names
--- web/html/packages.php | 2 ++ web/lib/pkgfuncs.inc | 29 +++++++++++++++++++++++++++++ web/template/pkg_details.php | 17 ++++++++++++++++- 3 files changed, 47 insertions(+), 1 deletions(-) diff --git a/web/html/packages.php b/web/html/packages.php index abc6637..9077ce2 100644 --- a/web/html/packages.php +++ b/web/html/packages.php @@ -64,6 +64,8 @@ if (current_action("do_Flag")) { $output = pkg_delete_comment($atype); } elseif (current_action("do_ChangeCategory")) { $output = pkg_change_category($atype); +} elseif (current_action("do_ChangeName")) { + $output = pkg_change_name($atype); } html_header($title); diff --git a/web/lib/pkgfuncs.inc b/web/lib/pkgfuncs.inc index 2024aeb..c2ca9bc 100644 --- a/web/lib/pkgfuncs.inc +++ b/web/lib/pkgfuncs.inc @@ -999,3 +999,32 @@ function pkg_change_category($atype) { return __("You are not allowed to change this package category."); } } + +/** + * Change package name + * + * @param string $atype Account type, output of account_from_sid + * @return string Translated error or success message + */ + + function pkg_change_name($atype) { + if (!$atype) { + return __("You must be logged in before you can edit package information."); + } + + if (isset($_GET["ID"])) { + $pid = $_GET["ID"]; + } else { + return __("Missing package ID."); + } + + $newname=$_POST['newname']; + + $dbh = db_connect(); + $q = "UPDATE Packages "; + $q.= "SET Name='".mysql_real_escape_string($newname)."' "; + $q.= "WHERE ID=".intval($pid); + db_query($q,$dbh); + return __("Package updated."); +} + diff --git a/web/template/pkg_details.php b/web/template/pkg_details.php index 0658063..0442a07 100644 --- a/web/template/pkg_details.php +++ b/web/template/pkg_details.php @@ -66,7 +66,22 @@ $out_of_date_time = ($row["OutOfDateTS"] == 0) ? $msg : gmdate("r", intval($row[ <div class="pgboxbody"> <p> - <span class='f2'><?php echo htmlspecialchars($row['Name']) . ' ' . htmlspecialchars($row['Version']) ?></span><br /> + <span class='f2'> + <?php + if (($atype == "Developer" or $atype == "Trusted User")) { + $edit_name = "<form method='post' action='packages.php?ID=".$pkgid."'>\n"; + $edit_name.= "<input type='hidden' name='action' value='do_ChangeName' />"; + $edit_name.= "<input type='text' name='newname' value='".$row['Name']."' />"; + $edit_name.= htmlspecialchars($row['Version']).' '; + $edit_name.= "<input type='submit' value='Change Name' />"; + $edit_name.= "</form>"; + echo $edit_name; + } + else { + echo htmlspecialchars($row['Name']).' ' . htmlspecialchars($row['Version']); + } + ?> + </span><br /> <span class='f3'><a href="<?php echo htmlspecialchars($row['URL'], ENT_QUOTES) . '">' . $row['URL'] ?></a></span><br /> <span class='f3'><?php echo htmlspecialchars($row['Description'], ENT_QUOTES); ?></span> </p> -- 1.7.5.2
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
On Wed, Jun 1, 2011 at 12:32 PM, Alexander Rødseth <rodseth@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
I'm glad the patch looks fine, though I'm not sure I understand the issue about dependencies?
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 <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. regards mar77i
On Wed, Jun 1, 2011 at 4:06 PM, Martti Kühne <mysatyre@gmail.com> 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.
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.
regards mar77i
On Wed, Jun 1, 2011 at 3:13 PM, D. Can Celasun <dcelasun@gmail.com> 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 1, 2011 at 4:35 PM, Martti Kühne <mysatyre@gmail.com> wrote:
On Wed, Jun 1, 2011 at 3:13 PM, D. Can Celasun <dcelasun@gmail.com> 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
Again, seems reasonable. I'll post an updated patch today.
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 <mysatyre@gmail.com> 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 <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. [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 6:54 PM, Lukas Fleischer <archlinux@cryptocrack.de> wrote:
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 on avoidance to compromise aur's DIY fun and asking immediate action from maintainers. +2 for still NO automagic replacement scripts, in that case. :p
On Wed, Jun 1, 2011 at 7:54 PM, Lukas Fleischer <archlinux@cryptocrack.de>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 <mysatyre@gmail.com> 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?
D. Can Celasun wrote:
On Wed, Jun 1, 2011 at 7:54 PM, Lukas Fleischer <archlinux@cryptocrack.de>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 <mysatyre@gmail.com> 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?
Hi, I'm in a hurry right now and I haven't read all of the replies to this topic in the other thread, so I'm sorry if this has already been discussed. I like the idea of enabling package renaming because I am generally in favor of breaking a few packages temporarily if it means that we can bring a naming scheme in line with official policy*. Overall it leads to less confusion. I suggest that name changes be logged (old name, new name, date, maybe user name, possibly hidden from public view) and that the log be made available via an RPC interface, a static plaintext page in a simple format, or a dynamic plaintext page with get variables similar to the query RPC interface. An accompanying RSS feed of the changes made in the last month would be good too. When a package complains about unavailable dependencies, users can check the log and inform the maintainer or update the package if it's theirs. AUR helpers will be able to scan for name-changes automatically too and handle that accordingly (e.g. by informing of the user or maybe even by handling it transparently). Log maintenance should require minimal effort as long as the data is stored in a parsable way. Entries could be purged after 1 year to avoid excessive clutter (which shouldn't be an issue anyway, because we won't be renaming many packages). Not effort is required to handle multiple renames either as the log can be scanned from top to bottom to find multiple changes, e.g. foo -> bar bar -> baz AUR helper: "Aha, foo is now baz." If the AUR detects that a package depends on a renamed package then it should send an automatic notification to the maintainer if possible because the AUR does seem to support some rudimentary dependency parsing, i.e. by naming deps on the package page.. Anything beyond that would be unnecessary in the presence of a log as the users will pass along the information. Parsing all PKGBUILDs would be imperfect and require too much overhead. Automatically updating packages would be disastrous. I hope that this is still on-topic. Regards, Xyne * That sounds eerily totalitarian. "Dear citizen, your package foo has been renamed Xte562FS42 according to party policy. Sugar rations have been raised this week to 15g."
On Wed, Jun 1, 2011 at 05:32, Alexander Rødseth <rodseth@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.
On Wed, Jun 1, 2011 at 4:00 PM, Daenyth Blank <daenyth+arch@gmail.com>wrote:
On Wed, Jun 1, 2011 at 05:32, Alexander Rødseth <rodseth@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.
On 1 June 2011 16:04, D. Can Celasun <dcelasun@gmail.com> wrote:
On Wed, Jun 1, 2011 at 4:00 PM, Daenyth Blank <daenyth+arch@gmail.com>wrote:
On Wed, Jun 1, 2011 at 05:32, Alexander Rødseth <rodseth@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.
On Wed, Jun 1, 2011 at 4:47 PM, Evangelos Foutras <foutrelis@gmail.com>wrote:
On 1 June 2011 16:04, D. Can Celasun <dcelasun@gmail.com> wrote:
On Wed, Jun 1, 2011 at 4:00 PM, Daenyth Blank <daenyth+arch@gmail.com wrote:
On Wed, Jun 1, 2011 at 05:32, Alexander Rødseth <rodseth@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).
On 1 June 2011 17:03, D. Can Celasun <dcelasun@gmail.com> 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 1 June 2011 17:23, Evangelos Foutras <foutrelis@gmail.com> wrote:
On 1 June 2011 17:03, D. Can Celasun <dcelasun@gmail.com> 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.
On Wed, Jun 1, 2011 at 5:27 PM, Evangelos Foutras <foutrelis@gmail.com>wrote:
On 1 June 2011 17:23, Evangelos Foutras <foutrelis@gmail.com> wrote:
On 1 June 2011 17:03, D. Can Celasun <dcelasun@gmail.com> 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.
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
2011/6/1 Lukáš Jirkovský <l.jirkovsky@gmail.com>
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 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.
On Wed, Jun 1, 2011 at 6:36 PM, Jakob Gruber <jakob.gruber@gmail.com> 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 1 June 2011 23:36, Jakob Gruber <jakob.gruber@gmail.com> 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.
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
On Wed, Jun 1, 2011 at 7:48 PM, Ray Rashif <schiv@archlinux.org> 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 <jakob.gruber@gmail.com> 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.
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...).
On Wed, Jun 1, 2011 at 8:01 PM, Alexander Rødseth <rodseth@gmail.com> 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 01, 2011 at 04:47:16PM +0300, Evangelos Foutras wrote:
On 1 June 2011 16:04, D. Can Celasun <dcelasun@gmail.com> wrote:
On Wed, Jun 1, 2011 at 4:00 PM, Daenyth Blank <daenyth+arch@gmail.com>wrote:
On Wed, Jun 1, 2011 at 05:32, Alexander Rødseth <rodseth@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.
+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.
On Wed, Jun 1, 2011 at 8:20 PM, Lukas Fleischer <archlinux@cryptocrack.de>wrote:
On Wed, Jun 01, 2011 at 04:47:16PM +0300, Evangelos Foutras wrote:
On 1 June 2011 16:04, D. Can Celasun <dcelasun@gmail.com> wrote:
On Wed, Jun 1, 2011 at 4:00 PM, Daenyth Blank <daenyth+arch@gmail.com wrote:
On Wed, Jun 1, 2011 at 05:32, Alexander Rødseth <rodseth@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.
+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.
participants (11)
-
Alexander Rødseth
-
Can Celasun
-
D. Can Celasun
-
Daenyth Blank
-
Evangelos Foutras
-
Jakob Gruber
-
Lukas Fleischer
-
Lukáš Jirkovský
-
Martti Kühne
-
Ray Rashif
-
Xyne