Re: new package: wip/dcc (Distributed Checksum Clearinghouses)

On Tue, Dec 23, 2008 at 09:33:44AM -0500, Greg Troxel wrote:
> 
> Petar Bogdanovic <[email protected]> writes:
> 
> >> I tried to build with MAKE_JOBS=4 on a dual-cpu machine and the build
> >> failed.  with MAKE_JOBS_SAFE=no it built.  Does this happen to you too?
> >
> > Yes (on a single-core Pentium 4, HT-off) -- It doesn't matter if
> > compiled directly with -j4 or through pkgsrc with MAKE_JOBS=4.
> >
> > I'll add MAKE_JOBS_SAFE=no.
> 
> OK, and if you are inclined file a bug upstream or fix it.  Usually we
> just note MAKE_JOBS_SAFE=no and move on...

I added MAKE_JOBS_SAFE=no for now.


> >> It would be nice for the server to be a separate package instead of an
> >> option, but that won't stop us from importing dcc into real pkgsrc.
> >
> > You mean something like mail/dcc{,-server}, similar to
> > sysutils/bacula{,-clientonly}?
> 
> Not really.  I mean something like amanda-common, amanda-client,
> amanda-server, where you could do
> 
>   pkg_add dcc
> 
> and use most things and then decide to install the server as
> 
>   pkg_add dcc-server
> 
> and have them both present.  It looks like with bacula you have to
> delete clientonly and replace.  This is awkward, but I bet it's that way
> because bacula doesn't have --enable-foo switches that are a) mutually
> exclusive and jointly exhaustive and b) can be built in any combination,
> finding self prereqs in ${PREFIX}.  IMHO upstream's lack of getting this
> right is the major reason behind not having split packages.  This is
> partly because most Linux packaging systems seem to be binary focused,
> building the whole thing and then picking off pieces, so it's not about
> the build.  The problem with the Linux way is that one has to
> build/install all the prereqs.  Since in that world it seems only
> distributions actually build and everyone else runs binaries, it works
> for them.
> 
> Options are necessary when enabling an option makes pervasive changes,
> such as enabled kerberos auth, and it's desirable to have them disabled
> sometimes, typically to avoid pulling in dependencies.
> 
> Split packages are nice when there is some base package and then some
> large extra chunk that many people won't want, especially when that
> extra chunk has much larger dependencies (like the gtk interface to a
> program).
> 
> Options are awkward when split packages are possible, because the bulk
> builds use the default options, and rebuilding is the only way to adjust
> them.
> 
> Split packages are awkward because they are extra work to maintain, even
> if upstream has fine-grained build controls that make it possible to
> just build what we want.

Thanks for that information, I always wondered what the deal is behind
options vs. split-packages.


> So, the question is whether there should even be options, or just build
> it all.  What bad thing would happen if all three options were defaulted
> to on?
> 
> I suspect Vernon would prefer that we always include dccd, so as to
> maximally encourage running a server.  It seems that dccd would be ok,
> just a few more bits.  Leaving the option lets someone who is for some
> reason both filtering mail and tight on space cope, but it seems dccd
> should be present in default builds.

The only disadvantage when adding dccd is that you'll pollute your
dcc_home with configuration files only used by dccd.. which is a bit
disencouraging if you just want to use one of the clients. At least
that's what my impression was when I first did a default install. :)


> (A nit is that --disable-server should also omit the server man pages.)

I tried to keep it default and follow what `make install' does. And it
leaves not just the man pages but also the configuration examples for
dccd. (and maybe a few other things)

Also there is no way to disable the cgi-bin stuff which is the only
reason why the package depends on perl.


> For dccm, it pulls in a dependency, and that would be nice to avoid.  I
> don't know how many people even want dccm (vs spamassassin or some other
> check aggregator) - I don't, so leaving it as an option defaulting to
> off makes sense.  If enough people cared a split package would be nice,
> but until they speak up I personally would not bother - they are already
> 80% of the way there with tweaking PKG_OPTIONS.dcc+=dccm and doing make
> replace.

I'm fine with that.

------------------------------------------------------------------------------