Re: Support for multiple versions in the repository?
On Mon, Aug 19, 2024 at 08:09:09AM GMT, RJ de Jager wrote:
> Hey all,
>
> We currently have setup an apt repository to store our internal
> packages. We have come across a problem where I would like to know if
> this problem is known and if what we want is possible.
>
> In our internal repository we would like to store multiple packages and
> every package will have lots of versions. We will also have version
> constraints between these packages. This is were we discovered the problem.
>
> Lets say we have package A and B in the repository. Both packages A and
> B have versions 1 and 2 in the repository. Package A version 1 depends
> on B version 1, and A version 2 depends on B version 2.
>
> So we have the following packages in the repository:
> - A[1]: depends B=1
>
> - A[2]: depends B=2
>
> - B[1]
>
> - B[2]
>
> If we were to do apt install A B=1, we get the following error:
>
> A : Depends: B (=2) but 1 is to be installed
>
> I would have assumed that the dependency resolver would be able to
> figure out that it should use version 1 of package A instead of version 2.
No, as you found out later, APT only installs the best version of a
package, called the candidate (usually the highest, but can be
overridden using pinning).
That's an important feature to narrow the search space and make the
behavior more deterministic. Of course this doesn't carry much weight
in this particular case, but imagine if they had ranges instead of
=, there'd be many weird possible combinations of allowed versions
- very complex.
And we'd rather fail than install a non-candidate version because
you don't expect to get a random (or fixed) old version because
the candidate isn't installable for some reason.
>
> I discovered that APT first will pick the version and then will do the
> version resolution. I also found out that a new solver(3.0) is being
> implemented which seemed like it would solve this situation. So I tried
> it with the --no-strict-pinning option, but the same problem persisted.
--no-strict-pinning should enable you to install those older
non-candidate versions, I can't say why it doesn't work for
you; you could dump the solver request without it by adding:
-o Dir::Log::Solver=/path/to/a/file
and send it and then maybe its possible to reproduce this locally,
but of course this may leak data.
There is one bug in the backtracking potentially where it gives
up too early, though it's not clear to me it's currently reachable.
>
> So my question is. Can APT handle dependencies in this way? If so, what
> are we doing wrong? if not, how should we solve this problem. I would
> not like to implement a dependency solver on top of apt.
The normal way to do this is to include the version in the package,
that is, a-1.0, b-1.0, then a-1.0 Depends b-1.0.
You could have them all Provides: a (= 1.0) and so on, and then use those
for Depends: a (= 1.0), this might even work if you also add a real
package a that Depends: a-2.0 (like the latest version), or any of
the versions of a, that is, a-2.0 | a-1.0. This may be useful for
convenience.
I mean the question ultimately is what you want to do, there isn't
much point in shipping a (= 1) and a (= 2) in the same repository,
you can't ship a bug fix to the a (= 1) version, and upgrades will
always install the a (= 2) one.
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en
Reply to: