[arch-proaudio] How to rename an AUR package
Hey friendly people, an AUR package that I have created needs an update to a new version. At the same time, I was notified that I should rename it, i.e. add suffix "-bin" as it is a binary package. Could someone please explain to me what would be the best way to do this? A high level explanation should suffice. I am especially concerned about how to let existing users know of the package rename. Many thanks! Daniel
you dont strictly need to do anything special - the AUR is not intended to be sane - but if it were an official package, and/or if there is a similarly named package in the official repos, then i think the thing to do is to add the original package name to its conflict-resolution arrays - e.g. for a package named 'foo': pkgname='foo-bin' provides=('foo') conflicts=('foo') replaces=('foo') how the web UI handles the renamed package, i have no idea
oh my - did i just give advice on how to distribute proprietary software? - please, no one tell the Great Gnu - /me is so embarrassed :)
On Thu, 24 Jan 2019 18:10:11 -0500, bill-auger wrote:
oh my - did i just give advice on how to distribute proprietary software? - please, no one tell the Great Gnu - /me is so embarrassed :)
Not necessarily. Sometimes GNU software is available as bin, too. Building software such as Icecat from source could takes hours on some machines. Upstream URL http://www.gnu.org/software/gnuzilla/ ;). https://aur.archlinux.org/packages/icecat/ https://aur.archlinux.org/packages/icecat-bin/ By providing FLOSS software as bin, it also could be easier to work around dependency issues. However, I'm not against proprietary software. I'm using https://aur.archlinux.org/packages/ocz-ssd-utility/ to get useful SMART output, since the output of smartctl is useless for my SSDs, let alone that I could update the firmware and other useful features are provided by this proprietary software. https://aur.archlinux.org/packages/ocz-ssd-utility/ Not only useful, but really needed for my machine: https://www.archlinux.org/packages/extra/any/intel-ucode
On 2019-01-24 23:29:38 (+0100), Daniel Appelt wrote:
an AUR package that I have created needs an update to a new version. At the same time, I was notified that I should rename it, i.e. add suffix "-bin" as it is a binary package. Which package is it specifically?
Regarding rename/merge [1]: File a merge request (it's a link on the package's site) towards the new name "${pkgname}-bin". This also moves the votes and comments over (after being approved by a TU). If you don't care about your (git and comment) history: Plainly request a delete of the package "$pkgname" (there's also a link for that on the package's site), after creating the "${pkgname}-bin" package. Update the pkgname in your PKGBUILD to the new name and push, after the merge request has been completed!
Could someone please explain to me what would be the best way to do this? A high level explanation should suffice. I am especially concerned about how to let existing users know of the package rename. Users can still find the package through search. However, if you intend to give some heads up, you could write a note on the old package's comment section.
Arch users are not considererd to be your every day novice Linux users, so I'm sure, they'll get along :D Best, David P.S.: Next time please use aur-general [2] or aur-requests [3] for this type of question (it is probably the more suited location). [1] https://wiki.archlinux.org/index.php/Arch_User_Repository#Other_requests [2] https://lists.archlinux.org/listinfo/aur-general [3] https://lists.archlinux.org/listinfo/aur-requests -- https://sleepmap.de
On 2019-01-24 17:55:24 (-0500), bill-auger wrote:
you dont strictly need to do anything special - the AUR is not intended to be sane - but if it were an official package, and/or if there is a similarly named package in the official repos, then i think the thing to do is to add the original package name to its conflict-resolution arrays - e.g. for a package named 'foo': If one ships binaries, it needs to be a -bin package [1]. The conflicts array is only required, in case there is a from-source version of the same software (not having the -bin appendix in its name).
[1] https://wiki.archlinux.org/index.php/Nonfree_applications_package_guidelines... -- https://sleepmap.de
Thank you all for your feedback. I was looking specifically for the information that David kindly provided. Am Fr., 25. Jan. 2019 um 12:29 Uhr schrieb David Runge <dave@sleepmap.de>:
On 2019-01-24 23:29:38 (+0100), Daniel Appelt wrote:
an AUR package that I have created needs an update to a new version. At the same time, I was notified that I should rename it, i.e. add suffix "-bin" as it is a binary package. Which package is it specifically?
openmusic{-bin}
Regarding rename/merge [1]: File a merge request (it's a link on the package's site) towards the new name "${pkgname}-bin". This also moves the votes and comments over (after being approved by a TU).
If you don't care about your (git and comment) history: Plainly request a delete of the package "$pkgname" (there's also a link for that on the package's site), after creating the "${pkgname}-bin" package.
Update the pkgname in your PKGBUILD to the new name and push, after the merge request has been completed!
Could someone please explain to me what would be the best way to do this? A high level explanation should suffice. I am especially concerned about how to let existing users know of the package rename. Users can still find the package through search. However, if you intend to give some heads up, you could write a note on the old package's comment section.
I have now created openmusic-bin from scratch via git clone. I merged the openmusic AUR repository into it in order to retain its history. Then, I created a new version for both packages and added an info message to the install script of openmusic asking users to switch. Finally, I filed the merge request via the AUR web interface. I guess, I should have waited some days before doing the latter in order to reach more users updating the original package. Oh well..
Arch users are not considererd to be your every day novice Linux users, so I'm sure, they'll get along :D
I have learned that lowering your expectations regarding other people seems to be a sensitive choice more often than not. Anyway, many thanks!! Daniel
participants (4)
-
bill-auger
-
Daniel Appelt
-
David Runge
-
Ralf Mardorf