Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230

 

 

 

deb package upgrade issue - old installation blocks upgrade

Ask for help with issues regarding the Installations of the Debian O/S.
Post Reply
Message
Author
Alber
Posts: 1
Joined: 2018-07-17 07:44

deb package upgrade issue - old installation blocks upgrade

#1 Post by Alber »

Summary:

I want to migrate a deb package "mypackage" in one single deb file with an upgrade, which depends on the new .Net runtime 2.1.2, which is the dependency "dotnet-runtime-2.1". The old "mypackage" depending on the old .Net 1.0.3 is still installed and is obviously blocking the installation of the new "dotnet-runtime-2.1".
My problem is, that I am not able to declare the dependency "dotnet-runtime-2.1".
Once I start the upgrade process, I will get:

Code: Select all

apt-get upgrade mypackage
Reading package lists... Done
Building dependency tree
Reading state information... Done
You might want to run 'apt-get -f install' to correct these.
The following packages have unmet dependencies:
 mypackage : Depends: dotnet-runtime-2.1 but it is not installed
E: Unmet dependencies. Try using -f.
The apt-get tool has access to the dotnet-runtime-2.1 and related packages, for example:

Code: Select all

apt-cache depends dotnet-runtime-2.1
dotnet-runtime-2.1
  Depends: dotnet-runtime-deps-2.1
  Depends: dotnet-hostfxr-2.1
The reason that apt-get denies to install dotnet-runtime-2.1 obviously is, that a dotnet 1.0.3 installation is on the system:

Code: Select all

dpkg -l | grep dotnet
ii  dotnet-dev-1.0.3                                   1.0.3-1  amd64  .NET Core SDK 1.0.3
ii  dotnet-host                                        2.1.2-1  amd64  Microsoft .NET Core Host - 2.1.2
ii  dotnet-hostfxr-1.0.1                               1.0.1-1  amd64  Microsoft .NET Core 1.0.0 - Host FX Resolver 1.0.1
ii  dotnet-hostfxr-1.1.0                               1.1.0-1  amd64  Microsoft .NET Core 1.1.0 - Host FX Resolver 1.1.0
ii  dotnet-sharedframework-microsoft.netcore.app-1.0.4 1.0.4-1  amd64  Microsoft .NET Core 1.0.4 - Runtime Microsoft.NETCore.App 1.0.4
ii  dotnet-sharedframework-microsoft.netcore.app-1.1.1 1.1.1-1  amd64  Microsoft .NET Core 1.1.1 - Runtime Microsoft.NETCore.App 1.1.1
If I would remove manually all old dotnet packages and the old mypackage, it would be no problem to install the new mypackage with dotnet-runtime-2.1 dependency.

But I want to do it in one single deb file.

Removing the old deb packages in a script, for example preinst, will fail, because the apt-get command blocks per design other apt-get commands.
Perhaps there is a trick to get rid of the "old installation" while the mypackage deb file will be upgraded.

I made some unsuccessful experiments with "Conflicts:" and "Replaces:"
For example my control file looks like

Code: Select all

Package: mypackage
Version: 1.0.1
Section: web
Priority: optional
Architecture: amd64
Depends: dotnet-runtime-2.1 (= 2.1.2)
Conflicts: mypackage, dotnet-dev-1.0.3, dotnet-host, dotnet-hostfxr-1.0.1, dotnet-hostfxr-1.1.0, dotnet-sharedframework-microsoft.netcore.app-1.0.4, dotnet-sharedframework-microsoft.netcore.app-1.1.1
Replaces: mypackage, dotnet-dev-1.0.3, dotnet-host, dotnet-hostfxr-1.0.1, dotnet-hostfxr-1.1.0, dotnet-sharedframework-microsoft.netcore.app-1.0.4, dotnet-sharedframework-microsoft.netcore.app-1.1.1
Homepage: http://www.myhomepage.com
Maintainer: MyCompany Ltd
Description: the description
 .
 detailed description
 .
How do I need to change my control file to get rid of the old dotnet installation, so that I am able to upgrade to the new dotnet version, and this all in all with one single deb file?

User avatar
stevepusser
Posts: 12930
Joined: 2009-10-06 05:53
Has thanked: 41 times
Been thanked: 71 times

Re: deb package upgrade issue - old installation blocks upgr

#2 Post by stevepusser »

If the new dotnet packages are conflicting somehow with the older version instead of upgrading over them, then you need to figure out why that's happening, then the Conflicts and Replaces should be added to the new dotnet packages as appropriate, not mypackage.

Also, why do you have mypackage conflict with itself? That sure doesn't look right.
MX Linux packager and developer

Post Reply