I am facing a problem with installing a package from Debian buster repo in a system which have two repos, this problem will affect the majority of the packages we deploy with puppet. Puppet is trying to install it form our local repo instead.
We are running multiple Ganeti cluster with Ubuntu 16 on the hardware as well as on the VM's. Now we decided to move to Debian stable for the hardware. We have a local repo in the company to provide our specific packages as well as some Ubuntu packages. I set up a new Ganeti cluster with Debian and some VM's for the testing phase.
the code I am using is the following:
package { 'haproxy':
ensure => latest,
}
on the VM I have installed the package haproxy manually because I had the error described below and I tried to see what will happen if the package is already present on the system so that I have the following situation:
# apt-cache policy haproxy
haproxy:
Installed: 1.8.19-1
Candidate: 1.8.19-1ppa1~xenial
Version table:
1.8.19-1ppa1~xenial 500
500 http://our.local.repo/local-xenial local-xenial/main amd64 Packages
*** 1.8.19-1 500
500 http://ftp.de.debian.org/debian buster/main amd64 Packages
100 /var/lib/dpkg/status
.....
.....
.....
When I run puppet agent on the node I get an error:
The following packages have unmet dependencies:
haproxy : Depends: libssl1.0.0 (>= 1.0.2~beta3) but it is not installable
E: Unable to correct problems, you have held broken packages.
Error: /Stage[main]/puppet_haproxy::Base/Package[haproxy]/ensure: change from 1.8.19-1 to 1.8.19-1ppa1~xenial failed: Could not update: Execution of '/usr/bin/apt-get -q -y -o DPkg::Options::=--force-confold install haproxy' returned 100: Reading package lists...
Building dependency tree...
Reading state information...
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
haproxy : Depends: libssl1.0.0 (>= 1.0.2~beta3) but it is not installable
E: Unable to correct problems, you have held broken packages.
So obviously puppet is trying to upgrade the package to 1.8.19-1ppa1~xenial which is related to the latest in the package resource.
I don't want to change the ensure attribute to installed or present, rather trying to get the code working on Ubuntu (which it does) as well as on Debian.
Changing the Pin-Priority will be also not a good idea, since we need some our standard packages from the local repo to be installed on each system without modifying the puppet code in each module.
The only work around I thought of is to add the attribute install_options so that the package resource will be as follows (I didn't test it yet):
if $facts['operatingsystem'] == 'Debain' {
package { 'haproxy':
ensure => latest,
install_options => ['-t', 'buster'],
}
} else {
package { 'haproxy':
ensure => latest,
}
}
But that means I have to modify all package resources in each module when a conflict occurs, which I want to avoid.
Is there a better way to achieve this?
Thanks
If you were installing packages manually from the command line, subject to the repository configuration you describe, then you would need to provide a command-line option each time, right? You would need either to specify a particular package version or to modulate the source list.
Puppet has no magic solution for that. If you need to override the repository configuration with respect to particular packages, then you need one way or another to provide attributes appropriate for that purpose on the affected Package resources. There are two basic avenues of approach:
Update your repository configuration so that you don't need extra options. For example, perhaps you can split your local repo into two, one that has lower priority than the distro, and one that has higher. Or perhaps you need a separate repo for Debian than for Ubuntu. OR
Modify Package resources declared in your Puppet manifests, possibly in a distro-specific way. Although you can use conditional statements to achieve any needed distro-specificity, I'd suggest instead a data-driven approach relying on parameterized classes and Hiera.