Mark J. Nelson wrote:
Howdy--
I'm working with Liane on directly generating an IPS repository from
an ON build. When I parallelized the publication of packages to the
repo, using a file: URI, I hit a PartialIndexingException.
I've worked around that by starting up pkg.depotd and using an http:
URI, but that seems suboptimal.
When I experimented with turning off automatic indexing at transaction
close, I found that I could switch back to a file: URI, and that (on
my machine, with moderate parallelism) this saved me 25% real build
time. (Building an entire ON repo dropped from 4m to 3m.)
Yep. solaris.py uses the same trick.
So that leaves me with a couple of questions for y'all:
1. The transaction.close() method already takes a refresh_index
argument, which defaults to True. My experiments above involved
setting refresh_index=False in my pkgsend invocation, and modifying
pkgsend on my system to pass pargs to t.close():
% diff publish.py /usr/bin/pkgsend
161c161
< pkg_state, pkg_fmri = t.close(abandon)
---
pkg_state, pkg_fmri = t.close(abandon, pargs)
%
...is it inappropriate to pass additional command line arguments on
from pkgsend to transaction methods (not just t.close, but all of em)?
Or is pkgsend intended to help keep private interfaces private? If
the latter, should pkgsend test for non-empty pargs after pulling out
the options that it parses?
See these RFEs:
http://defect.opensolaris.org/bz/show_bug.cgi?id=6572
http://defect.opensolaris.org/bz/show_bug.cgi?id=6573
But no, the pargs shouldn't be passed directly to close(). They need to
be specific options to the related pkgsend subcommand. The
pkgsend/pkgrecv command ideally should be wrappers around the
publication api, and then the publication api wrappers around the hidden
specifics. That ensures that if the publication api changes, that users
won't know, and that if the underlying apis change, the publication api
will hide that from pkgsend/pkgrecv.
I'd suggest something like --no-refresh.
Cheers,
--
Shawn Walker
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
