[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

speculations to characterize issues for Debian Enterprise



Reviewing Russ's list at
http://lists.debian.org/debian-enterprise/2010/08/msg00004.html

I'm trying to imagine what are the issues that if we were to solve them,
then Debian would work better in the Enterprise.

If I might hazard some speculations:

  - 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
  - So if heimdal was a config-time option OR if -noheimdal and -withheimdal
    packages were in Debian's archives, then a whole class of these private
    packages could go away, correct?
  - If that's correct, then for a large class of problems we just need to
    work with upstream to re-engineer the software to support config-time
    options or (I hate to say it) include in Debian multiple builds of
    packages for different use cases
  - Is this the same situation for the Cyrus SASL and OpenLDAP packages?
  - 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.
  - Could it be this simple:  just fix badly designed upstream software?

  - Another class of these packages occur to me as possibly just needing
    new upstream versions?
  - 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.

  - 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.

  - 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?

Which of these pieces seems big enough to be worth doing yet small enough
that we can build a project to solve it?

-- 
We are on a spaceship; a beautiful one.  It took billions of years to develop.
We're not going to get another.  Now, how do we make this spaceship work?
  -- Buckminster Fuller

CJ Fearnley                |  Explorer in Universe
cjf@CJFearnley.com         |  "Dare to be Naive" -- Bucky Fuller
http://www.CJFearnley.com  |  http://blog.remoteresponder.net/


Reply to: