---
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."'>
";
+ $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?

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.

> 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 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.