0

Is there a command line option that would tell apt or yum to not install the Depends packages of a package when installing?

In python/pip I could do this:

pip3 install --no-deps -r requirements.txt

Rationale

We build docker images on a regular basis. In those we have apt instructions to install packages which don't have a specific version attached to them. This process is very flaky because -- for no fault of our own -- suddenly our tests start breaking. We want to pin packages to their specific, tested versions.

Example:

$ sudo apt-get install python3=3.5.1-3

The problem is even if you set the desired package to a specific version, there are the dependencies inside that package which you have no control over. Those can be updated anytime and the rug will be pulled from under you.

We want to break each package into its complete list of dependencies and then tell apt/yum to only install that list and nothing further. We could always force developers to pin versions on those packages (especially if we put them all in a file like requirements.txt in the case of pip).

5
  • 2
    If you don’t want your Docker images to change, why do you rebuild them? Feb 29 '20 at 16:37
  • @StephenKitt The image just does not have one package in it. There's lot more. We want to have control over which package to upgrade if needed and when we must. Feb 29 '20 at 16:48
  • There is no way to skip dependencies with yum. It's possible with apt if the dependencies are recommended but not if they are required. It is possible to use rpm --nodeps or dpkg --ignore-depends but you'd render the packages unusable and yum upgrade` and apt-get upgrade would install the dependencies anyway. If you don't want a package to upgrade at all, then you can put it in the /etc/yum.conf config or use apt mark <package>. Feb 29 '20 at 17:18
  • @NasirRiley Thanks very much. At least now I know what we're up against. Feb 29 '20 at 18:29
  • Of course there are many packages in your images, you wouldn’t be facing these issues otherwise. My question still stands, but I’ll write up an answer to explain what I mean in more detail. Feb 29 '20 at 18:44
1

This won’t answer your question as stated, but should help you address the underlying scenario.

The traditional solution when one needs a source of packages with unchanging versions it to use private package repositories: mirror your chosen distribution’s repositories, and then leave them as-is, only changing packages piecemeal. The latter part is the painful component for testing, because different test scenarios often end up requiring different package upgrades compared to the common base repository, and then you end up maintaining multiple repositories...

Containers offer a much easier solution, when combined with image registries. Build you base test image as usual, with all your test dependencies:

FROM debian:10
RUN apt update && apt upgrade && apt install ...

Build that, and push it to your (private) registry with an appropriate tag (the date, if nothing better). Then your test scenarios can be based on that image, which won’t change. When you decide you need to upgrade a specific package, use a new image, with the appropriate dependency on your base image:

FROM testbase:20200229
RUN apt update && apt install ...

listing only the packages you want to upgrade (or install); that way, only those packages will be upgraded, unless they require a newer package in their own dependencies, in which case that will be pulled in too (but there’s no simple way to avoid that, so you’d have to deal with it anyway).

You can rebuild and push your base test image at regular intervals, without affecting existing tests as long as the latter reference the appropriate tagged image.

3
  • Thanks Stephen. I was thinking along the same lines too. So far this may be our best bet to deal with this. To know better what is in the Registry and whether it was changed from the last time or not, I have decided to not Tag them but use the sha256 digest (reported by the Registry). This value does not change if the underlying image has not changed in size (which is a good indication that no package upgrades/downgrades were made). Then I will also check this digest into our code or deriving images files (which depends on this image) and Feb 29 '20 at 19:09
  • ... they would know what to get. I just now need a notification of whether an image was pushed or not. This would give other teams time to decide if they want to start testing based on the new image or not Feb 29 '20 at 19:09
  • Indeed, the hash is better than a tag since it will always reflect the same content, I like that. Feb 29 '20 at 20:18
0

Dependencies are declared because whoever packaged the stuff determined they are needed, in the specified versions. Sure, they may overdo it, requesting stuff that isn't needed, or asking for new versions when older ones work just fine. But to check each and every possible scenario is a lot of work, packagers have finite time. When reasonable, they will be of the form "xyz version at least 5.3", and it should work with any later one.

If you don't install the requested dependencies, you are wandering into completely untested territory. It might work just fine, break in mysterious ways, or just explode in your face.

1
  • Hi I was planning on installing every single dependency recursively. I want to able to attach specific versions to each and every one of them. We are willing to spend the time. Unfortunately package installation tools do not give us the flexibility to do so Mar 1 '20 at 21:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.