version 1.1.17 of the DCC

Brandon Long
Thu Jan 9 21:05:49 UTC 2003

On 01/09/03 Vernon Schryver uttered the following other thing:
> > From: "Brian J. Murrell" <>
> > ...
> > I am building an RPM SPEC file for this puppy to make future upgrades
> > easy.  Since I am taking the time to do it, I may as well do it right
> > though.  I will be happy to share the SPEC file here once I am done if
> > anyone is interested.
> >
> > I notice that there are three "levels" of DCC packages, one each
> > layering on top of the other (dccproc, dccm and dccd, respectively).
> > I want to make RPMs in the same manner. ...
> Why make 3 packages?  There are three only because MAPS wanted to keep
> some of my code secret from MAPS's customers.  A dccproc package
> without dccd and dccm might make a little sense, but the dccm package
> is not worthwhile.  It's not as if the extra bits of the complete
> package are big enough to care about.

Its typical.  If the dccm is dependent on a specific version of
sendmail, then the dccm rpm is dependent on a specific sendmail rpm, but
people can install the other packages without it.

For mine, I just did clients and server, since I don't want to run the
dccd on any of the other machines, and I'm actually including local
configuration information in our local rpms.
> > ...
> > To support building in an RPM environment, I had to make the following
> > patches to the source:
> > ...
> What's wrong with the RPM spec file from Andrew Macpherson in the
> misc directory in the source.  For convenience, see  
> There were changes made to the DCC source to let that spec file work
> without local changes.  Is there something wrong with it?

For one, its dependent on sendmail being installed... which is certainly
not necessary for just dccproc.

Dependent in the "can't install with out using --nodeps" manner, of
course the binaries will work if installed.

Also, it installs dccd and add its to the init scripts to be started at
boot time, also not useful for client only scenarios.

The current one does split out the cgi programs as a separate package...
which makes sense in the rpm way, but is less necessary.

 "Every program has at least one bug and can be shortened by at least
  one instruction -- from which, by induction, one can deduce that every
  program can be reduced to one instruction which doesn't work."

More information about the DCC mailing list

Contact by mail or use the form.