Seems to be issue in f28 for obsoleting python [23]-modulemd and replacing with libmodulemd

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Seems to be issue in f28 for obsoleting python [23]-modulemd and replacing with libmodulemd

stan
I updated today, and looked at the conflicts.  One of them is for
python2-modulemd and python3-modulemd.  They are obsolete, being
replaced by libmodulemd.  But it isn't happening for some reason.

package python2-dnf-2.7.5-8.fc28.noarch requires python2-modulemd, but
none of the providers can be installed
  - package libmodulemd-1.0.4-2.fc28.x86_64 obsoletes python2-modulemd
< 1.3.4 provided by python2-modulemd-1.3.3-1.fc28.noarch
  - cannot install the best update candidate for package
python3-modulemd-1.3.3-1.fc28.noarch
  - cannot install the best update candidate for package
python2-dnf-2.7.5-8.fc28.noarch

package python3-dnf-2.7.5-8.fc28.noarch requires python3-modulemd, but
none of the providers can be installed
  - package libmodulemd-1.0.4-2.fc28.x86_64 obsoletes python3-modulemd
< 1.3.4 provided by python3-modulemd-1.3.3-1.fc28.noarch
  - cannot install the best update candidate for package
python3-dnf-2.7.5-8.fc28.noarch
  - cannot install the best update candidate for package
python2-modulemd-1.3.3-1.fc28.noarch

When I try to remove them so I can install their replacement,
libmodulemd, dnf rejects the transaction because it would lead to
removing itself.

Is the workaround to use rpm --force to remove python[23]-modulemd, and
then use rpm to install libmodulemd?

Or, is there a fix in the works, and I should just wait?
_______________________________________________
test mailing list -- [hidden email]
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Seems to be issue in f28 for obsoleting python [23]-modulemd and replacing with libmodulemd

Adam Williamson
On Wed, 2018-03-14 at 13:38 -0700, stan wrote:

> I updated today, and looked at the conflicts.  One of them is for
> python2-modulemd and python3-modulemd.  They are obsolete, being
> replaced by libmodulemd.  But it isn't happening for some reason.
>
> package python2-dnf-2.7.5-8.fc28.noarch requires python2-modulemd, but
> none of the providers can be installed
>   - package libmodulemd-1.0.4-2.fc28.x86_64 obsoletes python2-modulemd
> < 1.3.4 provided by python2-modulemd-1.3.3-1.fc28.noarch
>   - cannot install the best update candidate for package
> python3-modulemd-1.3.3-1.fc28.noarch
>   - cannot install the best update candidate for package
> python2-dnf-2.7.5-8.fc28.noarch
>
> package python3-dnf-2.7.5-8.fc28.noarch requires python3-modulemd, but
> none of the providers can be installed
>   - package libmodulemd-1.0.4-2.fc28.x86_64 obsoletes python3-modulemd
> < 1.3.4 provided by python3-modulemd-1.3.3-1.fc28.noarch
>   - cannot install the best update candidate for package
> python3-dnf-2.7.5-8.fc28.noarch
>   - cannot install the best update candidate for package
> python2-modulemd-1.3.3-1.fc28.noarch
>
> When I try to remove them so I can install their replacement,
> libmodulemd, dnf rejects the transaction because it would lead to
> removing itself.
>
> Is the workaround to use rpm --force to remove python[23]-modulemd, and
> then use rpm to install libmodulemd?
>
> Or, is there a fix in the works, and I should just wait?

Basically, what this is telling you is that the python2-dnf package
that dnf wants to include in the transaction has an explicit dependency
on 'python2-modulemd'. Which python2-dnf indeed does:

https://koji.fedoraproject.org/koji/rpminfo?rpmID=12982401

Requires python2-modulemd

If libmodulemd *obsoletes* python2-modulemd but doesn't *provide* it
(which appears to be what happened), dnf now has a conundrum, because
it can't both install the libmodulemd that should be included in the
transaction *and* keep python2-dnf happy. So it complains.

Patrick says he's actually run into this little mess this morning and
fixed it up, so I'd say just hang tight. (The retirement of modulemd
was apparently premature and is being undone, apparently).
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
_______________________________________________
test mailing list -- [hidden email]
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Seems to be issue in f28 for obsoleting python [23]-modulemd and replacing with libmodulemd

Patrick Uiterwijk
In reply to this post by stan
> I updated today, and looked at the conflicts.  One of them is for
> python2-modulemd and python3-modulemd.  They are obsolete, being
> replaced by libmodulemd.  But it isn't happening for some reason.
>
> package python2-dnf-2.7.5-8.fc28.noarch requires python2-modulemd, but
> none of the providers can be installed
>   - package libmodulemd-1.0.4-2.fc28.x86_64 obsoletes python2-modulemd
> < 1.3.4 provided by python2-modulemd-1.3.3-1.fc28.noarch
>   - cannot install the best update candidate for package
> python3-modulemd-1.3.3-1.fc28.noarch
>   - cannot install the best update candidate for package
> python2-dnf-2.7.5-8.fc28.noarch
>
> package python3-dnf-2.7.5-8.fc28.noarch requires python3-modulemd, but
> none of the providers can be installed
>   - package libmodulemd-1.0.4-2.fc28.x86_64 obsoletes python3-modulemd
> < 1.3.4 provided by python3-modulemd-1.3.3-1.fc28.noarch
>   - cannot install the best update candidate for package
> python3-dnf-2.7.5-8.fc28.noarch
>   - cannot install the best update candidate for package
> python2-modulemd-1.3.3-1.fc28.noarch
>
> When I try to remove them so I can install their replacement,
> libmodulemd, dnf rejects the transaction because it would lead to
> removing itself.
>
> Is the workaround to use rpm --force to remove python[23]-modulemd, and
> then use rpm to install libmodulemd?
>
> Or, is there a fix in the works, and I should just wait?

The modulemd package got retired in f28 and rawhide ahead of a new DNF that uses libmodulemd being available.
As a result, DNF could not be installed at the time.
Modulemd should only have been retired after the new DNF was available.

As soon as I found this out this morning, I unretired modulemd and retagged the modulemd build in them.
So modulemd should be back now, and sanity restored.
_______________________________________________
test mailing list -- [hidden email]
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Seems to be issue in f28 for obsoleting python [23]-modulemd and replacing with libmodulemd

stan
In reply to this post by Adam Williamson
On Wed, 14 Mar 2018 16:53:49 -0700
Adam Williamson <[hidden email]> wrote:

> Basically, what this is telling you is that the python2-dnf package
> that dnf wants to include in the transaction has an explicit
> dependency on 'python2-modulemd'. Which python2-dnf indeed does:
>
> https://koji.fedoraproject.org/koji/rpminfo?rpmID=12982401
>
> Requires python2-modulemd
>
> If libmodulemd *obsoletes* python2-modulemd but doesn't *provide* it
> (which appears to be what happened), dnf now has a conundrum, because
> it can't both install the libmodulemd that should be included in the
> transaction *and* keep python2-dnf happy. So it complains.
>
> Patrick says he's actually run into this little mess this morning and
> fixed it up, so I'd say just hang tight. (The retirement of modulemd
> was apparently premature and is being undone, apparently).

Thanks.  Will wait.
_______________________________________________
test mailing list -- [hidden email]
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Seems to be issue in f28 for obsoleting python [23]-modulemd and replacing with libmodulemd

stan
In reply to this post by Patrick Uiterwijk
On Wed, 14 Mar 2018 23:56:14 -0000
Patrick  マルタインアンドレアス  Uiterwijk <[hidden email]> wrote:

> The modulemd package got retired in f28 and rawhide ahead of a new
> DNF that uses libmodulemd being available. As a result, DNF could not
> be installed at the time. Modulemd should only have been retired
> after the new DNF was available.
>
> As soon as I found this out this morning, I unretired modulemd and
> retagged the modulemd build in them. So modulemd should be back now,
> and sanity restored.

Thank you.  With Adam's and your explanations, it's clear to me what is
happening, and my problem is solved.
_______________________________________________
test mailing list -- [hidden email]
To unsubscribe send an email to [hidden email]