FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux User Repository

 
 
LinkBack Thread Tools
 
Old 06-01-2011, 02:03 PM
"D. Can Celasun"
 
Default TUs can change package names

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).
 
Old 06-01-2011, 02:23 PM
Evangelos Foutras
 
Default TUs can change package names

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.
 
Old 06-01-2011, 02:27 PM
Evangelos Foutras
 
Default TUs can change package names

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.
 
Old 06-01-2011, 02:47 PM
"D. Can Celasun"
 
Default TUs can change package names

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.
 
Old 06-01-2011, 02:48 PM
Luk√°Ň° Jirkovsk√Ĺ
 
Default TUs can change package names

>
>
> 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
 
Old 06-01-2011, 03:26 PM
"D. Can Celasun"
 
Default TUs can change package names

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.
 
Old 06-01-2011, 03:36 PM
Jakob Gruber
 
Default TUs can change package names

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.
 
Old 06-01-2011, 03:43 PM
"D. Can Celasun"
 
Default TUs can change package names

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.
 
Old 06-01-2011, 04:48 PM
Ray Rashif
 
Default TUs can change package names

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
 
Old 06-01-2011, 04:54 PM
Lukas Fleischer
 
Default TUs can change package names

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

Thread Tools




All times are GMT. The time now is 06:44 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org