https://bugzilla.redhat.com/show_bug.cgi?id=2255805
Ondrej Mosnáček <omosnacek(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |prgutier(a)redhat.com
--- Comment #3 from Ondrej Mosnáček <omosnacek(a)gmail.com> ---
(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 are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
https://bugzilla.redhat.com/show_bug.cgi?id=2255805
Report this comment as SPAM:
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=rep...