[aur-general] [PATCH 1/1] TUs can change package names

[Xyne]

D. Can Celasun wrote:

> On Wed, Jun 1, 2011 at 7:54 PM, Lukas Fleischer <archlinux at 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 at 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 at 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."