Hi Brock,
On Wed, 2010-04-28 at 14:12 -0700, Brock Pytlik wrote:
> On 04/28/10 05:52 AM, Tim Foster wrote:
> > 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.
> I think this might be the bit that's bothering me.
I understand, and am a little uneasy about it too. As you say, it could
be a case of renaming, to 'pkgprepare' perhaps?
> 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).
That makes sense.
> 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).
So we do that to an extent already, in that
pkg.portable.os_sunos.get_file_type(..), having called file(1), needs to
parse the XML to determine what sort of XML it is, in order to dispatch
to the right dependency processing code, but I do agree.
In this case, I checked to see whether examining the
action.attrs["path"] for known SMF manifest locations would speed things
up, but over the course of an entire onnv-gate 'make gendeps' build, it
made virtually no difference (we don't have a lot of SMF manifests)
> 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).
I'll pass for the time being :-)
> 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?
Yes completely, thanks. If we get to the stage where we're doing that,
I'd be more than happy to move this stuff elsewhere.
> > I've got some sample text for pkgdepend(1) that tries to explain the
> > methods we use for dependency analysis.
> > 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"?
I'll go with the latter, thanks.
> > 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."?
Sounds good. Thanks again for the review.
cheers,
tim
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
