On Wed, Feb 27, 2008 at 10:37:51PM -0500, Stephen Talley 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.
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.
> > I'll make the same comment as I did for Nico -- ident lines are
> > comments in all files that aren't run through a processor which
> > understand "#ident" as a pragma. Thus shell scripts and makefiles
> > shouldn't have "#ident", but "# ident", just like any other comment.
>
> You're right, though this nit appears to be pandemic among the
> Makefile.sfw files in the SFW gate.
Yup. It's everywhere, but that's no reason to add it anew. Neither is the
fact that they'll all disappear when we move to mercurial.
> > fetchmail/Makefile.sfw:
> >
> > o line 36: This isn't used. (Same line in the other makefiles.)
>
> PKG is used as a parameter to the sunman.sh script on line 68.
Ah, okay. My browser search function got stuck on the first instance.
> > 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?
> > 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. 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.
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.
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".
> > 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".
> > 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.
> > 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. (Do be sure that it
wasn't not created just because you didn't have perms for the directory it
was in.)
> > SUNWmutt/protoype_com:
> >
> > o line 120ff: Is there a reason that message files are going in
> > /usr/share, rather than /usr/lib?
>
> mutt elects to put them there, and there appears to be precedent:
> SUNWpostgr-libs and SUNWgnome-dtlogin-integration, among others, also
> prefer /usr/share.
Doesn't mean they're right, just means they snuck by. You should easily be
able to change this by passing --localedir to configure.
> > 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.
I'm curious, though, if your list is in fact intended to be minimal, what
in SUNWkvm, SUNWcar, or SUNWcsr satisfied a direct dependency of procmail.
> > 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?
Danek
