The integration with the existing structure looks good to me in general.
The main bit that bothers me a bit is the pkg_attrs. I think it's a
little strange to have pkgdep able to add arbitrary set actions to the
manifest, can you elaborate a bit why these need to be in a set action?
If we do need to go down this road though, then I think it's probably
worth making it so that more than one set action can be added, instead
of only adding to the existing set action.
Other than that, I didn't see anything else that needed changing.
Thanks,
Brock
On 04/26/10 02:00 PM, Tim Foster wrote:
Hi all,
Sorry this is so late - I had been hoping to get this request for a code
review sent out last week.
I've got a code review at
http://cr.opensolaris.org/~timf/pkgdepend-smf
that I'd really appreciate a review of please.
This change looks for dependencies declared in SMF manifests delivered
by a package during the 'pkgdepend generate' phase of publication. It
resolves those SMF FMRIs to the SMF manifests that deliver them.
As a by-product, it sets an attribute on those packages that deliver SMF
manifests, 'smf.fmri' so you can do a pkg search using SMF FMRIs.
t...@tcx2200m2-02[1278] pkg search -l ':::svc\:/network/echo\:dgram'
INDEX ACTION VALUE PACKAGE
smf.fmri set svc:/network/echo:dgram
pkg:/service/network/[email protected]
It works by building internal dictionaries of all known SMF FMRIs at
publication time, and which files deliver those FMRIs. It uses those
dictionaries to lookup the file dependencies and generate depend
actions.
The 'pkgdepend resolve' phase is untouched by this changeset, and as
usual, resolves file names to package names.
I've included changes to importer.py to compute the same dependencies,
though this needs either the publishing build machine to include SMF
packages to satisfy those dependencies at publication time (unless
they're in the package for publication).
importer.py will try to seed those dictionaries using a search for SMF
manifests against the repository we're publishing to, pulling those
manifests directly from the repository. For now, that requires a http
depot - it currently reports a warning and continues if we're publishing
to a file-url. (I can change that once we're able to search against
file-based repositories).
I've done full ON builds on a test machine and have installed both the
built bits, as well as some ipkg zones using those published bits. I've
also added unit tests to exercise these changes.
Defect 15305 has an attachment that shows pkgdiff output of the resolved
manifests on an onnv-gate build before and after this changeset was
applied on the build machine.
I'll be available to work on feedback anytime between today and Friday,
but will be out of the office from Friday 30th, back on May 10th
assuming we survive the flight and initial few days in NZ :-)
cheers,
tim
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
