Specifying multiple binary package dependencies
Sam Varshavchik
mrsam at courier-mta.com
Sat Mar 19 01:12:07 UTC 2022
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>
More information about the ubuntu-users
mailing list