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, 04:58 PM
"D. Can Celasun"
 
Default TUs can change package names

On Wed, Jun 1, 2011 at 7:48 PM, Ray Rashif <schiv@archlinux.org> wrote:

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


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.
 
Old 06-01-2011, 05:01 PM
Alexander Rødseth
 
Default TUs can change package names

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...).
 
Old 06-01-2011, 05:03 PM
Martti Kühne
 
Default TUs can change package names

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

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

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

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

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.
 
Old 06-07-2011, 09:49 AM
Xyne
 
Default TUs can change package names

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

Thread Tools




All times are GMT. The time now is 01:39 AM.

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