isaexec.1:
- You refer to isalist(1), which claims to be obsolete. However, there's
no way to get isainfo(1) to produce the same kind of output. In
addition, isalist(5) doesn't mention the "i86" token that isalist(1)
spits out.
- isalist(5) should make it into the SEE ALSO section. Maybe
getexecname(3C)?
- Is it worth mentioning briefly an example of why one might bother with
isaexec on SPARC systems, or should you more strongly word it to
discourage use there?
- Is it worth explaining what the supported method is for executables on
other filesystems to invoke isaexec?
verexec.1:
- "subdirectory named of" -> "subdirectory named by"? In the same
sentence, move "in /etc/verexec.d" to right after "subdirectory"?
- "would be examine." -> "would be examined."
- In "Version definitions", is "1.0.0" greater than "1.0"? It is in
pkg(5), but from your description here, that doesn't appear to be the
case for verexec.
- I know that this isn't strictly a man-page issue, but do we want a
"vendor" override in addition to "site"? We might want to deliver
versions 2.4, 2.6, and 3.2, but have the system default be "2.6", and
still allow for that to be overridden by the sysadmin.
- Similarly to my comment above about isaexec'ed executables on different
filesystems, it would be nice to be able to use verexec in that
situation, too. But it's more difficult, since it's more work to write
your own version of verexec than it is for isaexec. Should there be a
library function that does this?
- Might as well use the full FMRI for automake: developer/build/automake.
- Should the exit status be something other than 1, if you want to
distinguish the exec'ed program's exit codes from something that went
wrong with verexec?
- A note about why to use isaexec(1) instead of verexec(1)? And possibly
why to not just use verexec(1) to exec an isaexec'ed executable?
Danek
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
