Re: wip/dcc -> pkgsrc?

On Sun, Dec 20, 2009 at 10:38:48AM -0500, Greg Troxel wrote:
> 
> Petar Bogdanovic <[email protected]> writes:
> 
> > On Fri, Dec 18, 2009 at 10:30:09AM -0500, Greg Troxel wrote:
> >> 
> >> In MESSAGE, I would drop the license bit, unless upstream has asked for
> >> it.  Perhaps change to just "Running dcc will query servers which have
> >> Terms of Use; see the license", because the code license part is no
> >> different than many other bits of non-free software.
> >
> > Even though I've never asked upstream, I'd like to keep that part. It's
> > not that much about the software than it's about people selling manpower
> > of others (all the work needed in order to keep the public DCC network
> > in shape).  Upstream really dislikes that behaviour and since people
> > sometimes just install stuff without ever reading LICENSE, it makes
> > sense to point that out---as clearly, as upstream does on the dcc
> > mailing list over and over again.. :)
> 
> The bit about using public servers is 100% ok.  That's really a separate
> issue from the license to use the code, even though it's also expressed
> that way.  My point is that we have a license-documenting scheme and it
> should be followed - adding things elsewhere because we don't think
> people are reading it is not ok.  I'll take a whack at rewording to keep
> the essence of what you describe without the license-reading-not-working
> implication.

On Sun, Dec 20, 2009 at 11:08:39AM -0500, Greg Troxel wrote:
> 
> I munged MESSAGE.  Let me know if you think it's ok - I suspect upstream
> would approve.

I like it and I'm sure upstream does too.


On Sun, Dec 20, 2009 at 10:38:48AM -0500, Greg Troxel wrote:
> 
> >> I don't understand about the passowrd/unique-id and if 'make install' in
> >> pkgsrc generates those.
> >
> > You mean INSTALL?  I'm just reproducing the steps from the official
> > Makefile since we never run `make install' there.  Without that part,
> > the default installation will create configuration files with default
> > (unsafe) secrets: `secret1' and `secret2'.
> 
> ah - the problem is that the comment that says like this:
> 
> # sample client-ID
> #   This password is generated by the installation script, and so may not be
> #   as secret as necessary.  This password must be the same as the password
> #   in the map file.  `make install` replaces "secretN" with a suitable
> #   password here and in the map file.
> [redacted-maybe-secret-not-sure]   secretN
> 
> where in my file the secretN is some longish hex string.  But not just
> where it is supposed to be used on the line with
> [maybe-secret-not-sure], but also in the line that says "replaces
> \"secretN\"".  Hence my confusion.

Ugh.. that's because of the overzealous SED_CMD1/SED_CMD2 patterns in
INSTALL.  Back then I didn't want to make them too specific in order to
avoid breakage after upgrades.

I could change the pattern from:

	SED_CMD1="-e s/secret1/${SECRET1}/"
	SED_CMD2="-e s/secret2/${SECRET2}/"

into something like:

	SED_CMD1="-e '/^[ 	]*[^#]/ { s/secret1/${SECRET1}/g; }'"
	SED_CMD2="-e '/^[ 	]*[^#]/ { s/secret2/${SECRET2}/g; }'"

which would skip comments while replacing secrets.

		Petar Bogdanovic

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev