Petar Bogdanovic <petar%smokva.net@localhost> 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...
>> 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.
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. (A nit is that --disable-server
should also omit the server man pages.)
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.
The real thing to optimize is the total work of all humans across both
maintaining and using the package, where that includes dealing with
packages being bloated as well as having to rebulid/etc., weighted by
what the people doing the work and contributing to pkgsrc care about.
That's my opinion, probably not entirely shared.
Attachment:
pgpowrF9bGvpg.pgp
Description: PGP signature
------------------------------------------------------------------------------
_______________________________________________ pkgsrc-wip-review mailing list pkgsrc-wip-review%lists.sourceforge.net@localhost https://lists.sourceforge.net/lists/listinfo/pkgsrc-wip-review