You are not logged in.

#1 2017-02-13 00:20:02

random-access
Member
Registered: 2015-11-27
Posts: 3

AUR-Package changed its name, question about migration.

Hi,

a package I maintain, mongochef, recently changed its name to studio-3t. As I didn't find an option to change the package name itself, I created a second package named studio-3t and updated mongochef once more to be working with the new URL etc.

My question is: What is the best way to tell new and existing users to switch to the new package ? I added a comment to the old package, but I don't know if everybody will read that. Is there any mechanism forcing people to change package if they use the old one?

Offline

#2 2017-02-13 00:39:14

mpan
Member
Registered: 2012-08-01
Posts: 1,188
Website

Re: AUR-Package changed its name, question about migration.


Sometimes I seem a bit harsh — don’t get offended too easily!

Offline

#3 2017-02-13 00:48:02

ayekat
Member
Registered: 2011-01-17
Posts: 1,589

Re: AUR-Package changed its name, question about migration.

Also perhaps `depends(studio-3t)` in the mongochef PKGBUILD, to make mongochef users actually aware of the new package.


pkgshackscfgblag

Offline

#4 2017-02-14 03:26:25

eschwartz
Fellow
Registered: 2014-08-08
Posts: 4,097

Re: AUR-Package changed its name, question about migration.

It is sufficient to use conflicts+provides to make sure the newly-named package installs okay and works as expected.

People using the package should ideally be subscribed to notifications for that package, in which case they will see the comment, and if not then they will probably investigate when the package turns out to no longer be on the AUR.
Unfortunately, replaces (which is used in the binary repos for this exact case) doesn't work in the AUR...
To aid in (re-)discoverability, you can add the old pkgname as a tag for the new pkgname, and it will cause a match when searching the AUR.

Making the old pkgname into a dummy package that pulls in the new name is ugly, won't play nice with the conflicts, and encourages the new name to be installed --asdeps regardless of the original install reason.
Just file a merge request for mongochef to be merged into studio-3t to make sure votes/comments/subscriptions are transferred over to the new package.


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

#5 2017-02-14 13:23:35

Lone_Wolf
Member
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 11,868

Re: AUR-Package changed its name, question about migration.

added :
@everyone : please ignore this and continue reading at post #8 by wormzy .
LW




Eschwartz wrote:

Unfortunately, replaces (which is used in the binary repos for this exact case) doesn't work in the AUR...

For those who put built aur-packages in a custom repo, replaces do work.
Also if this package is migrated into community at some point, replaces will work for it.

ramdom-access, I suggest to include replaces for those use-cases where it does work.

Last edited by Lone_Wolf (2017-02-15 12:38:17)


Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.


(A works at time B)  && (time C > time B ) ≠  (A works at time C)

Offline

#6 2017-02-14 13:36:53

eschwartz
Fellow
Registered: 2014-08-08
Posts: 4,097

Re: AUR-Package changed its name, question about migration.

For those who put built packages in a custom repo, they will still not know that the new pkgname exists. And if they do know it exists, using replaces as a method of informing them is kind of moot.

If this package is migrated into community, the replaces can be added at that time, of course, so I don't really see your argument.


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

#7 2017-02-14 14:00:54

Lone_Wolf
Member
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 11,868

Re: AUR-Package changed its name, question about migration.

added :
@everyone : please ignore this and continue reading at post #8 by wormzy .
LW


User X has custom repo Y for aur packages, X workflow includes never using makepkg i-flag and avoiding pacman -U .

X has foo in Y .

X notices foo is now called oof

X builds oof and adds it to Y

Y now has both oof and foo .

X does some other things, forgets oof replaces foo .

<time passes>

X runs pacman - Syu

without replaces : pacman sees foo is at latest version, nothing needs to be done with foo .

with replaces :
pacman sees foo is being replaced by oof , alerts X .
X confirms replacement and oof takes place of foo .

Last edited by Lone_Wolf (2017-02-15 12:39:14)


Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.


(A works at time B)  && (time C > time B ) ≠  (A works at time C)

Offline

#8 2017-02-14 14:21:31

WorMzy
Forum Moderator
From: Scotland
Registered: 2010-06-16
Posts: 11,787
Website

Re: AUR-Package changed its name, question about migration.

There is certainly nothing wrong with using replaces in this instance (and I would use it myself), but I think Eschwartz's point is that it doesn't answer OP's question, namely "What is the best way to tell new and existing users to switch to the new package ?". In the context of the AUR, replaces will not help achieve this, but in binary repositories, it will.

In terms of notifying users, I would add an post_install message to the old package directing them to the new one, bump the pkgrel so AUR helpers see it, and post a comment on the AUR page and sticky it. Maybe wait a week, then file the merge request. Some people will miss the messages, but there always will be. They can search aur-requests to see what happened to a package just like the rest of us.


Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD

Making lemonade from lemons since 2015.

Offline

#9 2017-02-14 14:37:25

eschwartz
Fellow
Registered: 2014-08-08
Posts: 4,097

Re: AUR-Package changed its name, question about migration.

As WorMzy said; I don't care if you use replaces, it certainly won't cause damage. It is just mostly orthogonal to the AUR, and while it does make things slightly easier for the unfortunately small percentage of Arch users who take advantage of custom repos, it certainly isn't a huge deal, and coming up with unlikely events on top of uncommon usage patterns won't make it any more generally useful for answering the OP's question.


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

Board footer

Powered by FluxBB