version 1.1.17 of the DCC
Fri Jan 10 14:08:32 UTC 2003

On Thu, Jan 09, 2003 at 01:05:49PM -0800, Brandon Long wrote:
> 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.

Or even more generally, if you combine the dccproc package and the
dccm package, you will force people who want to use dccproc to install
sendmail, just to meet the package dependency requirements.  I
certainly do not want to have sendmail on a machine where I am not
using 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.

And I guess you are using sendmail.  Or you don't mind installing
sendmail just because you want to use dccproc (or one of the other

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

Right.  Which is why I have gone back from just two to three packages

On Thu, Jan 09, 2003 at 05:54:05PM -0700, Vernon Schryver wrote:
> Dccd doesn't start unless the init scripts find a server-ID.

But even to just call the startup script on a non-server is

> I don't
> recall what if anything Andrew Macpherson's file does about server-IDs.

I don't see anything at all about server-ids in his RPM SPEC file.

> (In recent months, I've hacked basic installation mechanism to create
> a local, hopefully secret client-ID and password.)

Which seems like it has never made it into the RPM SPEC file.
Probably because it hasn't been updated since 1.1.4.

> What do you mean by "the version"?

Sorry.  The version number.  It's at 1.1.4.

> Is that some string that needs
> to be changed in the spec file for each DCC release?

Yup.  Second line:

%define version 1.1.4

> That's an object lesson for part of why I'm not enthused about RPMs
> or Packages.  Everyone has their own notions for how things should 
> be installed.

This is not an RPM issue.  This same issue is just as relevant for
.deb or whatever other packaging utility is used.  This is more of an
FHS issue.  I think most people involved in filesystem layout would
agree that /var is not the right place for executable binaries.

> Without sufficient political clout or at least investment
> in working the politics, it's impossible to get consensus on such
> issues as the choice among /var/dcc/libexec, /usr/lib/dcc, or somesuch.

Right.  But this is a packaging issue.  You can install them wherever
you want.  A distro vendor, especially one who wants to be FHS
compliant, will relocate them.  But since I would imagine most Linux
vendors want to be FHS compliant, making the RPM SPEC FHS compliant is a
good thing.

> Another and bigger part is dealing with the "dcc" user name and UID.
> How do you get a dcc name added to /etc/passwd?

Exactly the way Andrew did it in his RPM SPEC file.

> Most of /var/dcc/libexec are daemons, but there are some obscure things
> that administrators might use such as dblist.

OK.  Let's leave 'em in sbindir as the SPEC file does now.

> Could you involve Andrew Macpherson instead of me?  I boot Linux
> only when I need to test things.


> Primarily dcc_db, dcc_db.hash, flod, and

How about "whitelist"?


Brian J. Murrell
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <>

More information about the DCC mailing list

Contact by mail or use the form.