Re: speculations to characterize issues for Debian Enterprise
CJ Fearnley <cjf@CJFearnley.com> writes:
> - If each package in Debian supported a config-time option for the required
> functionality, then it might not need to be packaged as a private archive
We haven't done a lot of packaging because we needed to build things with
different options. I think the main place we've done that is with
OpenLDAP to build with SSL and we build that for other reasons as well.
Usually we've had to apply custom patches or other changes beyond just
building with different options.
> - In this class of problems, I just see it as buggy upstream software.
> Let's identify the issues and either submit bug reports or negotiate
> with upstream to design better software.
Sometimes it's bugs (our Cyrus SASL issue, for instance, I think is a
bug), but our weird custom Postfix stuff is just a strange Stanford
business requirement. We could probably find other ways of doing that.
To take another example, we basically fork Mailman and apply a *ton* of
changes. To some extent, that's an upstream deficiency, but the amount of
changes are rather huge and a lot of them involve UI design for Stanford
and customization to work with our web authentication system.
> - Another class of these packages occur to me as possibly just needing
> new upstream versions?
Yes, you can see a lot of backports in our archive. All the ~sbp stuff
are backports that we could be getting from backports.org in most cases if
someone got around to it. (Although there are a few exceptions where we
used the wrong version, like mailman.)
> - So that's an issue of helping Debian build packages for new
> upstreams and backporting them more quickly. Maybe we need more help
> on some of the Debian teams that maintain the package or negotiate
> to build a team to relieve an overworked DD.
Don't underestimate the importance of having control over exactly what
version you're running, though. For instance, I can't imagine using stock
Heimdal packages on our Kerberos KDC; I want to know exactly what version
I'm running. I can (and do) still start with the Debian packages, but in
addition to the set of patches that we apply (most of which are now
integrated upstream), I want to have total control over exactly what
revision of Heimdal is deployed.
This is our issue for Puppet, for example, because we have to synchronize
the server and the clients. Over time, Puppet will slow down the degree
to which it changes and this will be less of an issue.
> - Some of these packages are just not yet in Debian. So we need to form
> teams around these packages and get them into Debian, no?
> - Of course, some might have licensing issues, so some legal or
> political effort may be required.
There's definitely a lot of this. The packages are often obnoxious stuff
that's hard to get into Debian for legitimate reasons, like packages of
Oracle client libraries and things that link against them, or packages of
other commercial software like the Citrix ICA Client (although we're not
using that any more).
ApacheMQ packages would be great, for an example of this. We have
half-assed packages that sort of do what we want. The Shibboleth IdP is
similar. A bunch of the Perl modules in our archive are now in the Debian
archive but weren't in stable.
Most of my needs are around Java right now.
> - Some do not even have upstreams. So the issue is how to form an
> upstream project that can meet many people's needs with shared
> resources.
> Are there any other classes of issues that have led Stanford to needing
> to build so many customom packages?
We generally build a package for every class of server that stores our
local scripts for running that class of server. In theory, we could
potentially generalize some of that stuff, but it's a lot of work and in a
lot of cases I'm not sure it's worth it. For instance, we have reporting
scripts that we run on Kerberos KDCs that do lots of Stanford-specific log
and database analysis, and making those general enough for everyone to use
is a somewhat dubious proposition.
We also do a fair bit of local software development. Ideally, all that
could go into Debian, but some of this is very edge-case software and I'm
not sure that Debian really wants it. I'm slowly working on getting some
of that stuff, like all the AFS tools, into a generalized form, but it
takes a lot of time and effort.
> Which of these pieces seems big enough to be worth doing yet small
> enough that we can build a project to solve it?
I personally don't have a great answer for you right now because I've not
done enough analysis of our local respository to have a clear idea of what
we're doing. I hope to do that as part of moving to reprepro.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: