Virtual Package 1 Not Able to Replace Virtual Package 2

Here you can discuss every aspect of Debian. Note: not for support requests!

Virtual Package 1 Not Able to Replace Virtual Package 2

Postby engnfrc » 2020-12-11 19:45

Good Afternoon,

Long ago I had this concept working, but in trying it right now with some new packages on a different system, it doesn't appear to be working for me. Can someone help me figure out what I'm doing wrong? In short, two very simple packages, "project1" & "project2", both provide the virtual package "project", but when I try to install "project2" while "project1" is present I'm getting errors.

Package 1:

DEBIAN/control
Code: Select all
Package: project1
Version: 1.0
Priority: optional
Section: misc
Architecture: armhf
Provides: project
Conflicts: project
Replaces: project
Maintainer: Me
Description: Project1 Package.


/usr/local/share/project/README.txt
Code: Select all
Project1



Package 2:

DEBIAN/control
Code: Select all
Package: project2
Version: 1.0
Priority: optional
Section: misc
Architecture: armhf
Provides: project
Conflicts: project
Replaces: project
Maintainer: Me
Description: Project2 Package.


/usr/local/share/project/README.txt
Code: Select all
Project2


Installing Project1
Code: Select all
user@rpi:~/pkgs $ sudo dpkg -i project1_1.0_armhf.deb
Selecting previously unselected package project1.
(Reading database ... 70668 files and directories currently installed.)
Preparing to unpack project1_1.0_armhf.deb ...
Unpacking project1 (1.0) ...
Setting up project1 (1.0) ...


Installing Project2
Code: Select all
user@rpi:~/pkgs $ sudo dpkg -i project2_1.0_armhf.deb
Selecting previously unselected package project2.
dpkg: regarding project2_1.0_armhf.deb containing project2:
 project1 conflicts with project
  project2 provides project and is to be installed.

dpkg: error processing archive project2_1.0_armhf.deb (--install):
 conflicting packages - not installing project2
Errors were encountered while processing:
 project2_1.0_armhf.deb
engnfrc
 
Posts: 4
Joined: 2020-12-11 19:30

Re: Virtual Package 1 Not Able to Replace Virtual Package 2

Postby stevepusser » 2020-12-12 03:15

project1 conflicts with project
project2 provides project and is to be installed.


You have packages both provide and conflict with "project" in the control file. Seems pretty simple to me--try getting rid of the conflicts and replaces lines.
MX Linux packager and developer
User avatar
stevepusser
 
Posts: 12345
Joined: 2009-10-06 05:53

Re: Virtual Package 1 Not Able to Replace Virtual Package 2

Postby engnfrc » 2020-12-12 13:49

Project 2 should entirely replace Project 1 when installed.

As outlined in the Debian Policies, I believe what I'm wanting, and have seen work in the past, should still be possible.

https://www.debian.org/doc/debian-polic ... ships.html

Code: Select all
7.6.2. Replacing whole packages, forcing their removal
Second, Replaces allows the packaging system to resolve which package should be removed when there is a conflict (see Conflicting binary packages - Conflicts). This usage only takes effect when the two packages do conflict, so that the two usages of this field do not interfere with each other.

In this situation, the package declared as being replaced can be a virtual package, so for example, all mail transport agents (MTAs) would have the following fields in their control files:

Provides: mail-transport-agent
Conflicts: mail-transport-agent
Replaces: mail-transport-agent
ensuring that only one MTA can be unpacked at any one time. See Virtual packages - Provides for more information about this example.
engnfrc
 
Posts: 4
Joined: 2020-12-11 19:30

Re: Virtual Package 1 Not Able to Replace Virtual Package 2

Postby Head_on_a_Stick » 2020-12-12 14:33

Try adding project1 to the Conflicts list for project2 (and perhaps vice versa as well).
Black Lives Matter

Debian buster-backports ISO image: for new hardware support
User avatar
Head_on_a_Stick
 
Posts: 13450
Joined: 2014-06-01 17:46
Location: /dev/chair

Re: Virtual Package 1 Not Able to Replace Virtual Package 2

Postby engnfrc » 2020-12-12 15:00

Wouldn't that mask the issue? You wouldn't want to have to include every other package in existence that also has the same virtual type, that's just not sustainable. The Debian Policies page makes mention of the virtual type "mail-transport-type", through some Googling I found this page (https://packages.debian.org/stretch/mai ... port-agent) that shows packages having that virtual type. Curious what their DEBIAN/control file looks like, I picked a package, in this case "dma", downloaded it, and extracted its files, below is their control file's contents. With regards to using the virtual package name "mail-transport-agent", they appear to be doing something very similar to what I'm doing. I installed "dma" and subsequently installed "nullmailer" and "dma" was removed as I would have expected. I went ahead and included the control file for "nullmailer" below too.

Code: Select all
Package: dma
Version: 0.11-1build1
Architecture: amd64
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
Installed-Size: 145
Depends: ucf (>= 0.28), debconf (>= 0.5) | debconf-2.0, libc6 (>= 2.14), libssl1.1 (>= 1.1.0)
Conflicts: mail-transport-agent
Replaces: mail-transport-agent
Provides: mail-transport-agent
Section: mail
Priority: optional
Multi-Arch: foreign
Homepage: https://github.com/corecode/dma
Description: lightweight mail transport agent
 The DragonFly Mail Agent is a small Mail Transport Agent (MTA),
 designed for home and office use.  It accepts mails from local Mail
 User Agents (MUA) and delivers them either to local mailboxes or
 remote SMTP servers.  Remote delivery includes support for features
 such as TLS/SSL and SMTP authentication.
 .
 dma is not intended as a replacement for full-featured MTAs like
 Sendmail, Postfix, or Exim.  Consequently, dma does not listen on
 port 25 for incoming connections.
Original-Maintainer: Arno Töll <arno@debian.org>


Code: Select all
Package: nullmailer
Version: 1:2.1-5
Architecture: amd64
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
Original-Maintainer: David Bremner <bremner@debian.org>
Installed-Size: 431
Depends: lsb-base, systemd-sysv, debconf (>= 0.5) | debconf-2.0, libc6 (>= 2.15), libgnutls30 (>= 3.5.6), libstdc++6 (>= 5)
Recommends: rsyslog | system-log-daemon
Conflicts: mail-transport-agent
Replaces: mail-transport-agent
Provides: mail-transport-agent
Section: mail
Priority: extra
Homepage: http://untroubled.org/nullmailer/
Description: simple relay-only mail transport agent
 Nullmailer is a replacement MTA for hosts, which relay to a fixed set of
 smart relays. It is designed to be simple to configure and especially
 useful on slave machines and in chroots.
engnfrc
 
Posts: 4
Joined: 2020-12-11 19:30

Re: Virtual Package 1 Not Able to Replace Virtual Package 2

Postby engnfrc » 2020-12-12 15:09

I found the issue. I installed "dma" and "nullmailer" using apt and I installed "project1" and "project2" using "dpkg -i". If I try
Code: Select all
dpkg -i <package>
to install "dma" and "nullmailer" I see the same failures as with my packages. So now my question is, is there some way to make dpkg work in this scenario? Or do I have to use apt?
engnfrc
 
Posts: 4
Joined: 2020-12-11 19:30

Re: Virtual Package 1 Not Able to Replace Virtual Package 2

Postby ChrisDansword » 2020-12-23 07:49

I have a similar problem, as you will find out its complete solution. write please.You will help me a lot!
ChrisDansword
 
Posts: 1
Joined: 2020-12-23 07:42


Return to General Discussion

Who is online

Users browsing this forum: No registered users and 8 guests

fashionable