Small Patch

Vernon Schryver
Wed Apr 14 18:00:49 UTC 2004

> From: John Sutton 

> ...
> The alternative workaround is to do the build in a chroot environment. 

That is the only safe and sane tactic with source from strangers.
Otherwise you cannot be certain there is not a stray /bin/cp or
other installation command that needs attention.   The `chown` in
the DCC homedir/Makefile may be a case in point.

>                                                                    This 
> is not so difficult - see - but 
> obviously so not good as doing it "properly" in the Makefile.  But I'm 
> intrigued by what Vernon said about "the HINSTALL and DCC_PROTO_HOMEDIR 
> mechanism that is already in the Makefile"?  Maybe the means to do it 
> properly has been there all along but I never spotted it...

Some time ago, I added the HINSTALL and DCC_PROTO_HOMEDIR hooks to the
homedir/Makefile so that Andrew Macpherson's RPM control file could be
used to build RPMs.   I do not remember if he used chroot.  I removed
the RPM control file from the distribution a year or more after he lost
interest in the DCC and I had added programs including dccifd.

I will think about adding something such as `./configure --irootdir=XXX`
to do something like what I understand of DESTDIR.  If I do add it, it
will be not be called DESTDIR to avoid giving the impression that I'm
signing up for a FSF religious dogma--er--standard that I don't know,
don't understand, and might disagree with.

Please do not bother sending me replacement RPM control files.
Shipping the one I did was a mistake, because I never properly
debugged it, or even tested it.

I would also appreciate it if people who have not been in the software
business for many, many years would not go into the DCC public
package/tarball/RPM/whatever distribution business.  Whatever you do
for your own purposes is doubtless good, but people who have not been
around a long time rarely really understand that what makes very good
sense for locally often does not make sense elsewhere.  The lesson
that is very hard to learn is that if you think you know what other
situations need, you are probably wrong.  To put it another way, it
is not a coincidence that people with lots of experience distributing
software are less likely to redistribute packages/tarballs/RPMs/whatevers.
Replacing the bad set of choices in a distributed package with your 
own locallly good but globally bad choices is rarely helpful.

Vernon Schryver

More information about the DCC mailing list

Contact by mail or use the form.