Spec URL: https://gitlab.com/omos/fedora-package-review/-/raw/358b5abd4a00c67ed963df9e3e9f8a0db1e527aa/virtme-ng/virtme-ng.spec SRPM URL: https://download.copr.fedorainfracloud.org/results/omos/virtme-ng/fedora-rawhide-x86_64/06813984-virtme-ng/virtme-ng-1.19-1.fc40.src.rpm Description: Quickly build and run kernels inside a virtualized snapshot of your live system Fedora Account System Username: omos COPR build: https://copr.fedorainfracloud.org/coprs/omos/virtme-ng/build/6813984/ Note: The tool currently doesn't seem to work for me on Fedora 39 with the virtiofs backend (default), I have to pass --force-9p for it to work.
Taking this review.
> # virtme-ng provides a modified version of the original 'virtme' Python package. > # As that is also packaged in Fedora, we need to explicitly mark the conflict. > Conflicts: virtme As the old virtme has now been removed, can we make this Obsoletes+Provides that? And maybe also add symlinks so that the old commandline names point to the new ones?
(In reply to Neal Gompa from comment #2) > > # virtme-ng provides a modified version of the original 'virtme' Python package. > > # As that is also packaged in Fedora, we need to explicitly mark the conflict. > > Conflicts: virtme > > As the old virtme has now been removed, can we make this Obsoletes+Provides > that? It doesn't seem to be removed (yet?) - Pagure says it's maintained by @prgutier and there is no retirement commit: https://src.fedoraproject.org/rpms/virtme > And maybe also add symlinks so that the old commandline names point to the > new ones? Actually, it appears that all the command-line progs provided by virtme are already provided by virtme-ng with the same names and the CLI seems compatible (I think only --xen is missing from virtme-run, which is probably not too important). So fully replacing virtme with virtme-ng indeed seems to be the way to go (if Priscilla agrees). Anyway, what would be the logistics of replacing a package like this? First introduce virtme-ng with Obsoletes+Provides, then wait for it to get into a compose, and then retire virtme? What about stable releases? Keep virtme there and have virtme-ng with Conflicts: virtme if %{fedora} < 40?
You can have it upgrade the old version too. This is how it would work: Obsoletes: virtme < 0.1.1-25 Provides: virtme = %{version}-%{release} That would have it replace all existing versions of virtme and make it so that requests to install virtme would result in virtme-ng being installed. This is permitted even for stable Fedora releases, even with virtme only being retired and removed in Rawhide.
Actually I'm deprecating virtme for my own use. Glad we will have virtme-ng packaged!
v2: Obsolete virtme instead of just conflicting Spec URL: https://gitlab.com/omos/fedora-package-review/-/raw/204c0d125ad56f54967f8aad85a9df9de6f060a3/virtme-ng/virtme-ng.spec SRPM URL: https://download.copr.fedorainfracloud.org/results/omos/virtme-ng/fedora-rawhide-x86_64/06888397-virtme-ng/virtme-ng-1.19-1.fc40.src.rpm COPR build: https://copr.fedorainfracloud.org/coprs/omos/virtme-ng/build/6888397/
Copr build: https://copr.fedorainfracloud.org/coprs/build/6888436 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2255805-virtme-ng/fedora-rawhide-x86_64/06888436-virtme-ng/fedora-review/review.txt Please take a look if any issues were found. --- This comment was created by the fedora-review-service https://github.com/FrostyX/fedora-review-service If you want to trigger a new Copr build, add a comment containing new Spec and SRPM URLs or [fedora-review-service-build] string.
Review notes: * Package follows Fedora Packaging Guidelines * Package builds and installs * Package licensing is correctly handled * No serious issues from rpmlint PACKAGE APPROVED.
The Pagure repository was created at https://src.fedoraproject.org/rpms/virtme-ng
FEDORA-2024-c725578bd9 has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-c725578bd9
FEDORA-2024-c725578bd9 has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report.