[Pkg-puppet-devel] Bug#781231: Bug#781231: err: Could not retrieve catalog from remote server: Error 400 on SERVER: Unsupported osfamily (Debian) or lsbdistid () at /usr/share/puppet/modules/apt/manifests/params.pp:39

[Russ Allbery]

Christoph Berg <christoph.berg at credativ.de> writes:
> Re: Russ Allbery 2015-03-26 <87bnjfohg8.fsf at hope.eyrie.org>

>>> The Apt module seems to require the presence of the $lsbdistid fact,
>>> which is only available when lsb-release is installed. Neither
>>> puppet-module-puppetlabs-apt, puppet, nor facter have a Dependency (or
>>> any weaker relation) on that.

>> puppet-common Recommends lsb-release for exactly this sort of reason,
>> so it will be installed on Puppet clients in a default configuration.

> In this case, it's a hard dependency, and worse, it's not fixable
> by using puppet. :(

So, I took another look at this, but I'm really not sure what we can do
from a packaging perspective.  As you point out, there's no way to address
this with a dependency in the Puppet module package, since lsb-release is
required on the client, not the server.  I suppose we could raise the
lsb-release dependency in puppet to a full dependency... maybe that would
make sense?

Stig, what do you think of making lsb-release a dependency of puppet
instead of Recommends?  It's a little weird since Puppet itself doesn't
require this, but I think it's generally true that just about any
non-trivial Puppet policy ends up using the lsb facts, and lsb-release is
a pretty small package (apart from the python3 dependency, but I suspect
that will be pulled in anyway on most systems by something).

There really isn't any way to make the module robust against this fact
missing (other than it already is, with an error), since the module can't
know what to do if it doesn't know what version the client is running.
There's a whole bunch of conditional logic in the module that looks at
those variables.

-- 
Russ Allbery (rra at debian.org)               <http://www.eyrie.org/~eagle/>