On Fri, Aug 18, 2006 at 05:01:58PM -0700, Mike Kupfer wrote:
> Okay, I reviewed the updated webrev. It generally looks good to me.
> I've got 2 concerns:
>
> 1. The changes to usr/src/pkgdefs/Makefile.com are pretty opaque unless
> you're looking at usr/src/pkgdefs/Makefile.targ at the same time.
> Comments are definitely needed here.
I've added
# The following is some magic to generate the list of files that a package
# depends on (i.e., contains). The basic idea is to invoke an awk script
# using the $(...:sh) make construct. The awk script extracts the relevant
# file names from the prototype file(s), following "include" directives as
# needed. For path1=path2 constructs, use path2, because that's where
# we'll actually find the file. Type e, f, and v files are in the proto
# area. Type i files are in the current directory.
which is pretty similar to your suggested text.
> 2. It would be good if the Evaluation of 6460124 says something about
> "=" in package prototype files and why you had to change
> SUNWpcmci/prototype_com. I figured it out from the new comments in
> protodir.c, but having a brief explanation in Bugster would be helpful.
Okay, I'm putting the path that led to this in the evaluation. I can
repeat it here, if people are curious. Actually, I may just put it in the
description, since it's "Description-ish" and there's nothing proprietary
there, even though it talks about the ihv gate.
> In fact, the comment in protodir.c about how "e" files might just be a
> fragment was news to me. A sufficiently clever person might be able to
> deduce it from prototype(4), but I think it would be helpful information
> to include in your explanation. Or, if this is explained somewhere in
> the packaging developer guide, please include a pointer to the relevant
> section of the docs.
Well, it's not really a special property of editable files, but of class
action scripts, which just happen to be required for editable files. A
class action script can do all sorts of wild and crazy things to the files
it installs, including patching them together from fragments. Take a look
at just about any of the CAS we ship in ON, and the idea of "file
fragments" is a natural extension.
We don't go that far in ON yet (except for the couple of instances in the
IHV gate), but Mike S. tells me that we may be getting some like this in
the near future, so being able to deal with (or, as the case may be,
ignore) this situation is likely to be useful.
Danek
_______________________________________________
tools-discuss mailing list
[email protected]
