Re: Difficult Packaging Practices
- Date: Mon, 27 May 2019 07:38:38 -0400
- From: Sam Hartman <hartmans@xxxxxxxxxx>
- Subject: Re: Difficult Packaging Practices
>>>>> "Russ" == Russ Allbery <rra@xxxxxxxxxx> writes:
Russ> This is my experience as well. I've occasionally tried to get
Russ> people at work (at various jobs) interested in packaging
Russ> software for Debian, without all that much success. The
Russ> problem seems less any one specific thing and more that
Russ> they're perfectly content with a Debian package created by
Russ> running fpm on some install tree, and don't see the point in
Russ> doing any more work than that. This is usually in the context
Russ> where there's some other config management system in use, so
Russ> to them all the packaging format is good for is as a container
Russ> of files with a version number attached.
I've actually had somewhat better experience getting Debian packages
built at work.
At least in environments where we had a fairly pure Debian ecosystem (or
say Debian+windows) I've been able to get people to build packages using
.dscs. And if I set up the gitlab CI integration, that works fairly
At my current job we even have interest in making some of the stuff
comply with policy and actually make its way back into Debian.
And I think we're possibly getting close to activation energy to do some
But the challenge is that the quality bar you need for a local
environment is much lower than for inclusion in a global OS.
I think the only reason I've had different experience than Russ is two
factors. First, I didn't show people fpm (and they weren't aware).
Second, I think the environments I'm talking about are a lot smaller
than Russ where some of the social concerns really do matter.
At the first Cloud sprint we saw something similar. The folks from
Google wanted to talk to us about getting some of their cloud APIs into
But they wanted an approach that allowed them to build for all
distributions. They wanted us to accept fpm input as source.
They didn't actually want to do the work that is Debian specific in
I ended up saying that unfortunately, unless someone wanted to commit to
doing that work, it wasn't a package we as a community want to accept.
I tried to be more polite than that and to explain why those were our
To be clear, I'm sure there are a lot of ways our processes and
documentation can be improved.
However there are some reasons why what we're asking people to do is
hard. And I don't think we want to give up on those.