You are not logged in.
So I maintain the edk2-ovmf-fedora-bin from the AUR.
I want to simplify its name by renaming it into "edk2-ovmf-fedora" -- without the "-bin" suffix?
Why? It reads better and concise frankly. It feels like the suffix is unnecessary.
Regardless of whatever future discussion may happen below this post, I want this renamed. How to do it?
My current idea is the following:
1. Disown & orphan the package
2. Make a new AUR package named "edk2-ovmf-fedora"
3. Transfer all my files from the old package to the new
4. Rename a few things, and I'm done.
Is this the way I should go about it? Or is there a "non-invasive" way that I may possible not know yet?
Offline
If it's a (pre-built) binary package the suffix is mandatory.
https://wiki.archlinux.org/title/AUR_su … submission
But https://kojipkgs.fedoraproject.org/pack … noarch.rpm looks like it's just (binary) firmware and in that case it should not have had it itfp.
You cannot rename the repo yourself, https://wiki.archlinux.org/title/AUR_su … s#Requests
Offline
Thanks! I'll submit my request for a rename shortly.
Offline
But https://kojipkgs.fedoraproject.org/pack … noarch.rpm looks like it's just (binary) firmware and in that case it should not have had it itfp.
Upon looking further, I found the actual source code from the Fedora repos here: https://src.fedoraproject.org/rpms/edk2/tree/f42
Although it'd be absurd to pull this repo and manually compile all this into a separate Arch binary titled as "edk2-ovmf-fedora" when there are already Fedora package maintainers compiling & serving this package to their users with no additional cost --- that's just double my work with no actual benefits.
In this case, would submitting a Merge request in the AUR be a solid decision?
Last edited by ryanbarillos (2025-10-03 00:17:41)
Offline
cannot rename the repo yourself...
I understand that. However, I don't know what's the appropriate request to be made if I want a package to be renamed - Merge, Orphan or Delete.
I'm thinking merge is most appropriate, but merging my package into "edk2-ovmf-fedora" is invalid as it doesn't exist yet.
Any ideas?
Offline
Upon looking further, I found the actual source code from the Fedora repos here: https://src.fedoraproject.org/rpms/edk2/tree/f42
But that's edk2 while you're "only" packaging their copy of https://archlinux.org/packages/extra/any/edk2-ovmf/ ?
(And both packages are for "any" architecture, with the DBX bins being opaque payload from microsoft?)
I don't know what's the appropriate request to be made if I want a package to be renamed
Merge, I guess. It's not orphan, not delete and technically you're merging edk2-ovmf-fedora-bin and edk2-ovmf-fedora, except the latter doesn't (yet) exist.
Offline
I've done it like this in the past a few times :
Create the new package
Add a sticky comment on the aur page for the old package about the switch and that the old package will be deleted x weeks later.
(x = 4 worked fine for me.)
Once those x weeks have passed, submit a merge request.
Last edited by Lone_Wolf (2025-10-03 10:22:10)
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Once those x weeks have passed, submit a merge request.
Thanks for that! Just want to clarify what you mean by this:
So today I've made edk2-ovmf-fedora
My X will be 2 weeks from today (Oct. 4, so Oct 18 is the last day for users of the edk2-ovmf-fedora-bin package to migrate.)
Then after that's done, I do the following:
edk2-ovmf-fedora-bin >> Submit Request >> select "Merge" in Request type >> Merge into edk2-ovmf-fedora + Add comment as to why (maybe link this forum topic here)
Is this how I go about it?
Last edited by ryanbarillos (2025-10-04 13:28:44)
Offline
Yes, that should work.
The reason to use a merge request instead of a delete request is that with a merge request comments and notifications settings will be migrated to the new package..
Thus makes it easier for existing users to make the switch.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline