Danek, I've created an incremental webrev at:
http://cr.opensolaris.org/~talley/6667461_6667462_6667464.inc.1.2/ Comments inline: Danek Duvall wrote: > > > Everything else in the gate patches up man pages with a sed > > > script. Is there a reason you didn't do it the same way? > > > > Yes. I needed to be able to pass a stability parameter to the > > script, which varies depending on the man page. The sed scripts > > in other directories assume a single stability level for all man > > pages. > > Fetchmail uses the same commitment level for both its pages, as does > procmail, and slang; is there another reason those components use > the script? > > If it turns out that you do need this functionality in more than one > place, then you should probably put the script in a common location > (usr/src/tools), and run it from there, rather than checking in N > copies. And it could probably do all the work you're doing in > POST_PROCESS_MAN, thus simplifying the makefiles that use it. Good suggestion. Done. > Oh, and I just noticed that at least the one for slang is supposed > to be interpreted by "/bin/hs", which I'm pretty sure doesn't exist. Good eye. > > > o line 44: What's needed out of /usr/sfw/lib that doesn't come > > > from this consolidation (and hence the proto-area version > > > should be used)? (Same question for the other makefiles.) > > > > libssl.so is the dependency that fetchmail needs from > > /usr/sfw/lib. > > Right, but doesnt "--with-ssl=/usr/sfw" on line 110 pick that up? Check that; you're quite right, fetchmail does not require this line. Nor do any of the other Makefiles. > > > o line 88: why are you constructing fetchmailconf in the > > > makefile? Why not just create the file and install it? Or, > > > since you're doing nothing but execing the python file, why > > > not just put the python file in /usr/bin? Is that to > > > prevent the .pyc file from getting created in /usr/bin? > > > > This is to overcome a bug in fetchmail's build configuration; the > > fetchmailconf created in the build points to python files in a > > static location other than the one that I've configured. Since it > > is a one-line script, it is easier to overwrite it than patch it. > > I'd rather see the code of delivered files kept out of the makefile. > It's just not a natural place for it. You don't need to patch it, > you can just check in a copy of the file you want to deliver. That's a fair request. > But see later for why you might not need it at all. > > > > mutt/Makefile.sfw: > > > > > > o line 129: This should probably be /etc/mutt. > > > > I wavered a bit on this, but ultimately chose /usr/share/mutt/etc > > in part to avoid conflicts with the system's /etc/mime.types. But > > I can be persuaded here. > > No need to put it in /etc directly; /etc/mutt would be appropriate. > It should go under /etc because /usr is not always mounted > read-write, so it's inappropriate to put possibly editable > configuration files there. Okay, agreed. > Note that while you should probably set sysconfdir to /etc/mutt, > actually shipping anything there requires a second package, since > svr4 packages can't deliver files both under /usr and outside it. > But you needn't actually ship anything in /etc, and just ship sample > config files in /usr/share/doc/mutt or whatever, possibly with a > note at the top saying where they should go if people want to > install them. I'll opt for a separate root package -- the system Muttrc should be sourced when mutt starts. > Also note that any config file that you intend to be edited needs to > be of type "e" (editable), and be associated with a class other than > "none", such as "renamenew", or "preserve". Yep. > > > mutt/stubman.sh: > > > > > > o line 34: I don't think this manpage needs to be run through > > > eqn. And not tbl as it stands, though it should have the > > > standard table in an ATTRIBUTES section with the Interface > > > Stability entry. > > > > The ATTRIBUTES section with stability is added by the sunman.sh > > script, along with the other man pages. > > Okay. Still don't need the "e". Yep. Removed. > > > slang/Makefile.sfw: > > > > > > o line 82: likely sysconfdir should be under /etc here, too. > > > > Given that slsh is not going to be widely used, I don't feel it > > merits cluttering up /etc with slsh.rc. As with mutt, I can be > > persuaded. > > And same argument for it. Same solution. > > > SUNWfetchmail/prototype_com: > > > > > > o line 55: We don't typically ship .pyo files. > > > > Why ship the .pyc but not the .pyo? It seems only the .py is > > necessary. > > Typically the .pyc file is created by python when the .py file is > loaded, and you don't want random turds flying around that aren't > tracked by the packaging system if at all possible. > > However, if it's not being created, then I wouldn't ship it either. > In fact, if that's the case, I'd not bother with the script at all, > and just ship fetchmailconf.py as /usr/bin/fetchmailconf. Done. > > > SUNWprocmail/depend: > > > > > > o Is there a reason you're not using the common depend file > > > here? > > > > These are the the direct dependencies I determined that procmail > > needs. If there is a common dependency subset that every package > > should use, shouldn't this comment also apply to > > SUNW{slang,mutt,fetchmail} as well? And is this subset documented > > somewhere? > > The "common subset", which is a bit broken, is in the depend file in > ../common_files. If you don't need anything outside of those > packages, you should use that instead. See packages which set > DATAFILES in their Makefiles to see how that's done. Done. > > > All of these components are at least partly GPLv2. Typically > > > legal requires that we put a disclaimer at the top of the > > > copyright file (or something similar, but that's how we've been > > > interpreting that requirement) that says that we're distributing > > > under v2 *only*, and no later versions. Were you not asked to > > > do something like this? > > > > Thanks for the pointer -- I did not notice this requirement in the > > TOI pdf. I'll add the preambles to each. Incidentally, I notice > > there are several GPL-licenced packages in SFW that don't carry > > this preamble. > > I'm not talking about the TOI, I'm talking about the legal review > done in the OSR. The lawyers tend to send you an annoy-o-gram about > this for every GPL blob that's imported. You did file OSRs for > these four components, right? Yes, of course. My recollection is that the only instructions from the OSR tool w.r.t. the copyright file was that it had to reflect the license(s) from the product. No mention, AFAICR, of the aforementioned ammendment. Steve -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 185 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/sfwnv-discuss/attachments/20080228/5fde2463/attachment.bin>
