Specifying multiple binary package dependencies

[Ralf Mardorf]

On Fri, 18 Mar 2022 21:12:07 -0400, Sam Varshavchik wrote:
>Ralf Mardorf via ubuntu-users writes:
>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.

Yes and no. I'm saying this, but I don't claim that it's the policy of
the DEB package management, since I didn't read the manual.

>> 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.

For good reasons not all distros split one source from upstream into
several packages.

>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?

I don't know. It for sure doesn't "affect the logic" of foo does depend
on bar and also not that all installed foo-1.1-1 packages get replaced
by foo-1.1-2 as well as bar-1.1-1 get replaced by bar 1.1-2 packages
that are available by an update via a repository.

I don't know if changing a package release protects against partial
upgrades. You manually made a partial upgarde! The partial upgarde
obviously is the culprit here. A partial upgrade cannot happen, if all
packages are available.

>[...] to be able to seamlessly install the newer collection
>of packages and automatically deinstall older subpackages, including a
>retired subpackage?

Again, I didn't read the DEB package management policy. However, all
package managements have a policy to workaround some particular issues,
such as "never do partial upgrades" (e.g. by manually upgrading and
providing an incomplete set of packages). A well known workaround for
some other issues is the "epoch:", used by almost all, if not all
package managements. Ubuntu specific is the relationship package release
[x]ubuntu[y].

There are a lot of known pitfalls package managements need to take into
account. Another one is the dependency cycle.

Fazit:

Again, I'm just guessing! The culprit probably is, that you enforced a
partial upgrade by not providing all packages. A partial upgrade
might be possible, if just the debian/ubuntu package release is
different, but epoch and version are identical. Probably including the
debian/ubuntu package release as a dependency requirement is ignored.
Maybe there is a good reason to ignore the package release, to
workaround another issue.