Specifying multiple binary package dependencies

[Sam Varshavchik]

Ralf Mardorf via ubuntu-users writes:

> On Fri, 18 Mar 2022 18:15:49 -0400, Sam Varshavchik wrote:
> >Depends: libcourier-auth (= 0.71.4-147)
> >
> >This dependency is now broken. Am I missing something about how
> >dependencies are supposed to work?
>
> Hi,
>
> I don't know. However, to me it doesn't make much sense that software
> version 0.71.4 is broken by installing software version 0.71.4, even if
> you install different package versions.
>
> See https://en.wikipedia.org/wiki/Soname .
>
> You are only changing the package's version and not the software's
> version, 0.71.4-1, 0.71.4-2, 0.71.4-n should be compatible versions.

Are you saying that if I increased the version number, instead of the  
release number, dpkg's resulting behavior would be different? I don't recall  
reading anything in the copious documentation that suggested that.

I'm just trying to make sure that I'm declaring the dependencies between my  
packages correctly, and dpkg does the right thing, and how dependencies are  
set up. I would think that the only thing that matters is that I have a  
"newer" set of packages that I have as an "update" to an existing,  
installed, set of packages.

> However, splitting one thing from upstream to several packages is
> tricky and asking for this kind of trouble, if runtime binaries and
> runtime libraries are split into two packages, one for the binaries and

Well, I am the upstream. I simply wanted to have an easy way to have  
installable debs. And to test the upgrade behavior I'm just bumping the  
release number in debian/changelog, to simulate upgrades, rather than  
actually going through and bumping the version number in my own upstream  
package, building a new tarball, then building it.

I just want to make sure I understand this correctly: if I increased the  
version number of these packages, rather than incrementing the release  
number, this affects the logic that dpkg uses to validate package  
installations and dependencies?

Having thought about this a bit more: I'm not sure I'm getting what's the  
conceptual difference between an upstream releasing a new version and a  
Debian/Ubuntu maintainer issuing a new release in order to correct a  
packaging defect. Don't either case simply boils down to "here are a new set  
of packages, install them without breaking their dependency"? What's the  
difference?

And what, specifically, goes into which package, and why; where are all the  
binaries and shared libraries in all of this -- that's something else, I'm  
just focused on working out the declared dependencies between packages. Or,  
are you saying that dpkg looks into the actual stuff in each package, and  
not merely it's declared version and release, in order to work out the  
dependencies?

I would think that when you have two sets of: a main package and its  
subpackages – the currently installed ones and the ones you're trying to  
install – you just want all your packages to be updated and all  
dependencies to be satisfied. And a "packaging defect" would certainly  
include things like reorganizing how the upstream package gets broken up  
into a main package and various sub-packages, due to a packaging mistake.

So, I want to understand what's the difference here: don't you want, in  
either case, to be able to seamlessly install the newer collection of  
packages and automatically deinstall older subpackages, including a retired  
subpackage? Let's say your packaging mistake was either having a separate  
subpackage, which should now be rolled into the main package, or be renamed.  
Is it possible to specify a consistent set of rules of dependencies between  
a main package, and each subpackage, that would allow you to have a seamless  
update without, as I've observed, ending up with a combination of newer and  
older half-installed/uninstalled packages? Why did dpkg install a newer set  
of packages, breaking a dependency of an existing package, that wasn't  
updated?

And I have to go back to the simple way I specify this in my rpm packages.  
Each subpackage simply specifies:

Requires: $PACKAGE=$VERSION-$RELEASE

Then, if this subpackage is retired in a newer set of packages – and it is  
completely immaterial when the $VERSION or the $RELEASE gets bumped, it's a  
"newer" set of packages and it's all that matters – it gets automatically  
uninstalled and removed when upgrading this collection of packages; either  
that or rpm refuses to install anything, and tells me that I'm stupid and I  
don't have the right set of packages to install.

I'm just trying to figure out the equivalent way to set this up in deb  
packages, and I keep missing the mark. No matter how I specify all the  
relationships documented here: https://www.debian.org/doc/debian-policy/ch- 
relationships.html – no matter I come up with I end up with something  
broken. Either dpkg proceeds and installs the newer packages, without  
uninstalling the simulated "retired" subpackage, or it throws a bunch of  
errors and leaves things half installed or uninstalled.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-users/attachments/20220318/f6887576/attachment.sig>