On 04/28/10 05:52 AM, Tim Foster wrote:
Hi Brock,
Thanks for taking a look.
On Tue, 2010-04-27 at 14:24 -0700, Brock Pytlik wrote:
The integration with the existing structure looks good to me in general.
Cool.
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?
It felt like a natural place to put it - automatically generated
metadata that applies to the package as a whole.
An alternative would be to add more attributes to the file action for
the SMF manifest itself, describing the SMF FMRIs that the file
delivers, but I was under the impression there was a consensus that
adding set actions was preferable to adding more attributes to 'file'?
In terms of doing it in pkgdepend vs. elsewhere, we're already examining
the package contents to produce dependency information at this point,
doing some analysis on every file in the package. We expect developers
to go through the pkgdepend phase prior to publication anyway - we could
add a third phase of automatic file-content sniffing, but that'd be more
work for the developer imho.
I think this might be the bit that's bothering me.
pkgdepend/"autogenerate pkg dependencies for me" seems like a fairly
narrow and defined operation. Adding (potentially) arbitrary package
attributes doesn't really seem within its purview. I guess I'm ok w/
doing it this one time inside pkgdep, but I don't want it to set a
precedent. So, if we get a lot more things that decide they need to do
similar things, I think a new command/interface is called for. To
simplify it for the end developer, we could always wrap
pkgdepend/pkgannotate/pkgprocess/etc... inside a single subcommand that
handled the basic use case(s).
So, thinking about this somemore, I'm guessing that the reason, other
than having two commands, that we don't want to process the things twice
is that parsing the smf manifest is somewhat expensive (and it's
somewhat silly to do twice). I think the real solution here is that
dependencies.py needs some refactoring (Bart's mentioned this to me as
well since pkgdep and the importer don't blend) so that it doesn't
expose (only) a "gimme file paths" interface to the world. That's
definitely not in scope for your wad (unless you decide you want it).
In short, I'm ok w/ how things are for now, but if we see more pkg attr
like things appearing, or if we simply decide to rework the
dependencies.py interface so that we wouldn't need to parse the manifest
twice, I'd like to see the pkgattrs bits removed from the pkgdep world
and added to a different command/interface/etc...
Does that seem reasonable?
The alternative would be to add this auto-generated information during
the package publishing step, but that'd slow down package publishing on
subsequent attempts to publish tweaked versions of a package where the
developer is happy with the dependencies we've already worked out.
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.
I agree - I've made that change in the latest webrev, in src/pkgdep.py
Other than that, I didn't see anything else that needed changing.
I've got some sample text for pkgdepend(1) that tries to explain the
methods we use for dependency analysis. I'm not happy with the text for
python dependencies, but wasn't sure how else to summarise the
conditions under which we gather python dependency information (short of
reproducing the excellent block comment in
src/modules/flavor/python.py :-)
I'll reproduce that my suggested man page additions here for
convenience:
---
Several aspects of delivered files are used as sources of
dependency information:
ELF ELF headers in delivered files are analyzed for
dependency information, with the -k and -D options
modifying how that information is obtained. For
more details on ELF dependencies, please see ldd(1)
and the Solaris Linker and Libraries Guide.
I'm not sure that -k or -D change how the information is obtained. Maybe
"used"? Or maybe "modifying the information obtained"?
Scripts Shell scripts that contain '#!' lines referencing
an interpreter will result in a dependency on the
package that delivers that interpreter.
Python Python scripts are analyzed as above. In addition,
any imports the script declares may also serve as a
source of dependency information.
Instead of "as above" maybe "first as scripts."?
Hard links Hard links in manifests will result in a
dependency on the package that delivers the link
target.
SMF SMF service manifests delivered that include
"require_all" dependencies will result in a
dependency on the package that delivers the SMF
manifest that provides that FMRI.
---
The updated webrev is at
http://cr.opensolaris.org/~timf/pkgdepend-smf
Thanks again for the comments, they're much appreciated.
cheers,
tim
Thanks,
Brock
[snip]
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
