upgrade 30 to 32

[Patrick Dupre]

Hello,

running:
dnf system-upgrade download --releasever=32
I get:

Modular dependency problem:

 Problem: conflicting requests
  - nothing provides module(platform:f31) needed by module
gimp:2.10:3120191106095052:f636be4b-0.x86_64
Error: 
 Problem 1: package perl-PDL-LAPACK-0.12-1-1.fc30.x86_64 requires
libperl.so.5.28()(64bit), but none of the providers can be installed
  - package perl-PDL-LAPACK-0.12-1-1.fc30.x86_64 requires perl(:MODULE_COMPAT_5.28.2), but
none of the providers can be installed
  - perl-libs-4:5.28.2-444.fc30.x86_64 does not belong to a distupgrade repository
  - problem with installed package perl-PDL-LAPACK-0.12-1-1.fc30.x86_64
  - package perl-libs-4:5.28.2-442.module_f32+8059+8a5cccba.x86_64 is filtered out by
modular filtering
  - package perl-libs-4:5.28.2-442.module_f32+8111+66b92dcd.x86_64 is filtered out by
modular filtering
  - package perl-libs-4:5.28.2-444.module_f32+8513+01a85d28.x86_64 is filtered out by
modular filtering


However

gimp is not installed


dnf remove perl-PDL-LAPACK
Modular dependency problem:

 Problem: conflicting requests
  - nothing provides module(platform:f31) needed by module
gimp:2.10:3120191106095052:f636be4b-0.x86_64
No match for argument: perl-PDL-LAPACK
No packages marked for removal.
Dependencies resolved.
Nothing to do.
Complete!


How to solve the issue?

===========================================================================
 Patrick DUPRÉ                                 | | email: pdupre(a)gmx.com
 Laboratoire interdisciplinaire Carnot de Bourgogne
 9 Avenue Alain Savary, BP 47870, 21078 DIJON Cedex FRANCE
 Tel: [phone]
===========================================================================

[Michael Young]

On Mon, 1 Jun 2020, Patrick Dupre wrote:

>  Hello,
>
>  running:
>  dnf system-upgrade download --releasever=32
>  I get:
>
>  Modular dependency problem:
>
>  Problem: conflicting requests
>   - nothing provides module(platform:f31) needed by module
> gimp:2.10:3120191106095052:f636be4b-0.x86_64 
This can be solved by
dnf module reset \*

>  Error:
>  Problem 1: package perl-PDL-LAPACK-0.12-1-1.fc30.x86_64 requires
> libperl.so.5.28()(64bit), but none of the providers can be installed
>   - package perl-PDL-LAPACK-0.12-1-1.fc30.x86_64 requires perl(:MODULE_COMPAT_5.28.2), but
> none of the providers can be installed
>   - perl-libs-4:5.28.2-444.fc30.x86_64 does not belong to a distupgrade repository
>   - problem with installed package perl-PDL-LAPACK-0.12-1-1.fc30.x86_64
>   - package perl-libs-4:5.28.2-442.module_f32+8059+8a5cccba.x86_64 is filtered out by
> modular filtering
>   - package perl-libs-4:5.28.2-442.module_f32+8111+66b92dcd.x86_64 is filtered out by
> modular filtering
>   - package perl-libs-4:5.28.2-444.module_f32+8513+01a85d28.x86_64 is filtered out by
> modular filtering 
It looks like there is no  perl-PDL-LAPACK package in Fedora 32, so you 
will probably have to delete that package for the update to work.

 	Michael Young

[Patrick Dupre]

Every time that I upgrade my system I have to do remove
all my own packages (40).

Would dnf module reset \*
do the job?

This is really annoying.



===========================================================================
 Patrick DUPRÉ                                 | | email: pdupre(a)gmx.com
 Laboratoire interdisciplinaire Carnot de Bourgogne
 9 Avenue Alain Savary, BP 47870, 21078 DIJON Cedex FRANCE
 Tel: [phone]
===========================================================================


> Sent: Monday, June 01, 2020 at 11:08 PM
> From: "Michael Young" <m.a.young(a)durham.ac.uk&gt;
> To: "Community support for Fedora users"
<users(a)lists.fedoraproject.org&gt;
> Subject: Re: upgrade 30 to 32
>
> On Mon, 1 Jun 2020, Patrick Dupre wrote:
> 
> > Hello,
> >
> > running:
> > dnf system-upgrade download --releasever=32
> > I get:
> >
> > Modular dependency problem:
> >
> > Problem: conflicting requests
> >  - nothing provides module(platform:f31) needed by module
gimp:2.10:3120191106095052:f636be4b-0.x86_64
> 
> This can be solved by
> dnf module reset \*
> 
> > Error:
> > Problem 1: package perl-PDL-LAPACK-0.12-1-1.fc30.x86_64 requires
libperl.so.5.28()(64bit), but none of the providers can be installed
> >  - package perl-PDL-LAPACK-0.12-1-1.fc30.x86_64 requires
perl(:MODULE_COMPAT_5.28.2), but none of the providers can be installed
> >  - perl-libs-4:5.28.2-444.fc30.x86_64 does not belong to a distupgrade
repository
> >  - problem with installed package perl-PDL-LAPACK-0.12-1-1.fc30.x86_64
> >  - package perl-libs-4:5.28.2-442.module_f32+8059+8a5cccba.x86_64 is filtered
out by modular filtering
> >  - package perl-libs-4:5.28.2-442.module_f32+8111+66b92dcd.x86_64 is filtered
out by modular filtering
> >  - package perl-libs-4:5.28.2-444.module_f32+8513+01a85d28.x86_64 is filtered
out by modular filtering
> 
> It looks like there is no  perl-PDL-LAPACK package in Fedora 32, so you 
> will probably have to delete that package for the update to work.
> 
>  	Michael Young
> _______________________________________________
> users mailing list -- users(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]
>

[Samuel Sieb]

On 6/1/20 2:15 PM, Patrick Dupre wrote:
>  Every time that I upgrade my system I have to do remove
>  all my own packages (40). 
If they are compiled against versions of libraries that are getting 
replaced, then yes.  You could setup a vm to compile the libraries on 
the new release and include those in the update.

>  Would dnf module reset \*
>  do the job?
>  
>  This is really annoying. 
It's also unnecessary.  dnf will automatically do that for this release.

[Patrick Dupre]

Hello,

What I would like is to have an automatic removing of my own packages
telling me which packages have been removed.

Then I will rebuild my packages.

===========================================================================
 Patrick DUPRÉ                                 | | email: pdupre(a)gmx.com
 Laboratoire interdisciplinaire Carnot de Bourgogne
 9 Avenue Alain Savary, BP 47870, 21078 DIJON Cedex FRANCE
 Tel: [phone]
===========================================================================


> Sent: Monday, June 01, 2020 at 11:37 PM
> From: "Samuel Sieb" <samuel(a)sieb.net&gt;
> To: users(a)lists.fedoraproject.org
> Subject: Re: upgrade 30 to 32
>
> On 6/1/20 2:15 PM, Patrick Dupre wrote:
> > Every time that I upgrade my system I have to do remove
> > all my own packages (40).
> 
> If they are compiled against versions of libraries that are getting 
> replaced, then yes.  You could setup a vm to compile the libraries on 
> the new release and include those in the update.
> 
> > Would dnf module reset \*
> > do the job?
> > 
> > This is really annoying.
> 
> It's also unnecessary.  dnf will automatically do that for this release.
> _______________________________________________
> users mailing list -- users(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]
>

[Samuel Sieb]

On 6/1/20 3:25 PM, Patrick Dupre wrote:
>  What I would like is to have an automatic removing of my own
> packages
>  telling me which packages have been removed. 
Add "--allowerasing" to the dnf command and check the list of removed 
packages.  It will also be in the dnf history.

[Samuel Sieb]

On 6/1/20 2:00 PM, Patrick Dupre wrote:
>  running:
>  dnf system-upgrade download --releasever=32
>  I get:
>  
>  Modular dependency problem:
>  
>    Problem: conflicting requests
>     - nothing provides module(platform:f31) needed by module
> gimp:2.10:3120191106095052:f636be4b-0.x86_64 
This can be ignored.  dnf will resolve it in the end.

>  Error:
>    Problem 1: package perl-PDL-LAPACK-0.12-1-1.fc30.x86_64 requires
> libperl.so.5.28()(64bit), but none of the providers can be installed
>     - package perl-PDL-LAPACK-0.12-1-1.fc30.x86_64 requires perl(:MODULE_COMPAT_5.28.2),
> but none of the providers can be installed 
This must be something you installed yourself.  It's not from Fedora.

>  dnf remove perl-PDL-LAPACK
>  No match for argument: perl-PDL-LAPACK 
You can either try adding "--allowerasing" to the system-upgrade command 
or try:
dnf remove perl-PDL-LAPACK*
Maybe the version number is part of the name.

[Patrick Dupre]

This has been solved by

rpm -e perl-PDL-LAPACK-0.12-1-1.fc30.x86_64

===========================================================================
 Patrick DUPRÉ                                 | | email: pdupre(a)gmx.com
 Laboratoire interdisciplinaire Carnot de Bourgogne
 9 Avenue Alain Savary, BP 47870, 21078 DIJON Cedex FRANCE
 Tel: [phone]
===========================================================================


> Sent: Monday, June 01, 2020 at 11:09 PM
> From: "Samuel Sieb" <samuel(a)sieb.net&gt;
> To: users(a)lists.fedoraproject.org
> Subject: Re: upgrade 30 to 32
>
> On 6/1/20 2:00 PM, Patrick Dupre wrote:
> > running:
> > dnf system-upgrade download --releasever=32
> > I get:
> > 
> > Modular dependency problem:
> > 
> >   Problem: conflicting requests
> >    - nothing provides module(platform:f31) needed by module
gimp:2.10:3120191106095052:f636be4b-0.x86_64
> 
> This can be ignored.  dnf will resolve it in the end.
> 
> > Error:
> >   Problem 1: package perl-PDL-LAPACK-0.12-1-1.fc30.x86_64 requires
libperl.so.5.28()(64bit), but none of the providers can be installed
> >    - package perl-PDL-LAPACK-0.12-1-1.fc30.x86_64 requires
perl(:MODULE_COMPAT_5.28.2), but none of the providers can be installed
> 
> This must be something you installed yourself.  It's not from Fedora.
> 
> > dnf remove perl-PDL-LAPACK
> > No match for argument: perl-PDL-LAPACK
> 
> You can either try adding "--allowerasing" to the system-upgrade command 
> or try:
> dnf remove perl-PDL-LAPACK*
> Maybe the version number is part of the name.
> _______________________________________________
> users mailing list -- users(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]
>

[Michael Schwendt]

On Mon, 1 Jun 2020 23:12:06 +0200, Patrick Dupre wrote:

>  This has been solved by
>  
>  rpm -e perl-PDL-LAPACK-0.12-1-1.fc30.x86_64 
The good old "rpm -e perl-PDL-LAPACK" would have been enough for the
most common use case.

[Samuel Sieb]

On 6/2/20 12:14 AM, Michael Schwendt wrote:
>  On Mon, 1 Jun 2020 23:12:06 +0200, Patrick Dupre wrote:
>  
> > This has been solved by
> >
> > rpm -e perl-PDL-LAPACK-0.12-1-1.fc30.x86_64
>  
>  The good old "rpm -e perl-PDL-LAPACK" would have been enough for the
>  most common use case. 
Maybe you missed the original message where he tried the equivalent of 
that with dnf.  There's something funny with the package name.  I'm 
guessing that the version is part of the name for some reason.

[Michael Schwendt]

On Tue, 2 Jun 2020 00:25:59 -0700, Samuel Sieb wrote:

>  >> rpm -e perl-PDL-LAPACK-0.12-1-1.fc30.x86_64  
>  > 
>  > The good old "rpm -e perl-PDL-LAPACK" would have been enough for the
>  > most common use case.  
>  
>  Maybe you missed the original message where he tried the equivalent of 
>  that with dnf.  There's something funny with the package name.  I'm 
>  guessing that the version is part of the name for some reason. 
Then whoever created that package needs to be told. ;-)

[Samuel Sieb]

On 6/2/20 12:57 AM, Michael Schwendt wrote:
>  On Tue, 2 Jun 2020 00:25:59 -0700, Samuel Sieb wrote:
>  
> >>> rpm -e perl-PDL-LAPACK-0.12-1-1.fc30.x86_64
> >>
> >> The good old "rpm -e perl-PDL-LAPACK" would have been enough for the
> >> most common use case.
> >
> > Maybe you missed the original message where he tried the equivalent of
> > that with dnf.  There's something funny with the package name.  I'm
> > guessing that the version is part of the name for some reason.
>  
>  Then whoever created that package needs to be told. ;-) 
My understanding was that it was a package he made himself, so I think 
he's been told.

[Tim]

Patrick Dupre wrote:
> > This has been solved by
> >
> > rpm -e perl-PDL-LAPACK-0.12-1-1.fc30.x86_64 
Michael Schwendt:
>  The good old "rpm -e perl-PDL-LAPACK" would have been
> enough for the
>  most common use case. 
Don't you have to do up to the first dot?

i.e.  rpm -q perl-PDL-LAPACK-0
 
-- 
 
uname -rsvp
Linux 3.10.0-1127.8.2.el7.x86_64 #1 SMP Tue May 12 16:57:42 UTC 2020 x86_64
 
Boilerplate:  All unexpected mail to my mailbox is automatically deleted.
I will only get to see the messages that are posted to the mailing list.

[Michael Schwendt]

On Tue, 02 Jun 2020 19:29:51 +0930, Tim via users wrote:

>  Patrick Dupre wrote:
>  >> This has been solved by
>  >>
>  >> rpm -e perl-PDL-LAPACK-0.12-1-1.fc30.x86_64  
>  
>  Michael Schwendt:
>  > The good old "rpm -e perl-PDL-LAPACK" would have been enough for the
>  > most common use case.  
>  
>  Don't you have to do up to the first dot?
>  
>  i.e.  rpm -q perl-PDL-LAPACK-0 
No. The simplified package naming scheme here is N-V-R.A as in
"Name-Version-Release.Arch", and specifying the name would be enough when
only a single package of that name is installed. Even if the name included
one or more characters like '-', '_' or '.'. In dependencies
related
output you will also see N:E-V-R.Arch if the Epoch tag is set for a
package, but when using rpm/dnf, specifying the Epoch is only needed in
corner-cases.

Putting a numerical "Version" and '.' characters into the package name
can
break quite some tools and scripts that strictly expect a simple N-V-R scheme.