On Feb 26 09:54:18, anth...@cathet.us wrote:
> Jan Stary writes:
> > groff-1.21p8 ships with grap2graph(1)
> > which metions grap(1) in its manpage.
> >
> > But neither grap(1) nor the grap(1) manpage seems to be present.
>
> grap(1) is one of the many historical companion programs to troff
> (like chem, pic... see http://troff.org/prog.html for more). I don't
> think groff contains an implementation, but it's appropriate for the
> manpage to link to it (and since it's a package manpage we don't
> really need to be messing with the text of it anyway).
>
> We don't appear to have a package for grap. An implementation is
> here: http://www.lunabase.org/~faber/Vault/software/grap/
> I will submit a port for it sometime after unlock.
>
> > Also, grap2graph(1) wants convert(1), without having that as
> > a dependency:
> >
> > $ grap2graph
> > /usr/local/bin/grap2graph[83]: grap: not found
> > /usr/local/bin/grap2graph[83]: convert: not found
> >
> > Similarly for pic2graph(1) and eqn2graph(1).
> >
> > What do? I understand groff(1) is a legacy,
>
> I wouldn't call the groff package legacy. Using groff for manpages may be
> on the way out (as mandoc gets more feature-complete), but some people do
> use groff for other typesetting purposes.
Please excuse my ignorance: what would be an example
of a serious typesetting done decidedly in (g)roff
these days?
> > but as long as we need it (some ports do),
> > should we also get all its dependencies?
>
> Maybe, but ImageMagick is a fairly large dependency, and this is a fairly
> fringe program within groff...
I agree with both points.
> A run dep may be appropriate, but I'm
> inclined to just leave the dep out.
Yes.
On Feb 26 18:03:19, pascal.stu...@cubes.de wrote:
> There's graphics/grap.
Would it be appropriates to have graphics/grap
as a RUN dependency of groff? grap itself has
no other dependencies.
> Adding either graphics/grap or graphics/ImageMagick as a run dep would
>
> 1) pull in a shitload of other dependencies for groff.
Not via grap. But via ImageMagick, very much.
> It's in our best
> interest to keep that dependency list as small as possible since groff
> unlocks thousands of packages in bulk builds.
>
> 2) create a dependency loop as both of these are USE_GROFF.
>
> So it's impossible for groff to depend on them.
OK.
On Feb 26 18:38:56, es...@nerim.net wrote:
> no kitchen sink.
> that's the non-technical work of maintainer: figure out what dependencies to
> leave out because they're optional, and only cater to a fringe of users.
>
> My opinion on this is that this ought to be documented.
>
> DESCR is the ideal place to mention optional software that MAY be installed
> on top of the main package to yield more functionality.
>
> This also makes it obvious that the missing optional dependency is
> intentional.
>
> Patches for adding optional dependency verbiage to various ports DESCR are
> welcome.
Index: pkg/DESCR
===================================================================
RCS file: /cvs/ports/textproc/groff/pkg/DESCR,v
retrieving revision 1.3
diff -u -p -r1.3 DESCR
--- pkg/DESCR 4 Dec 2011 15:41:26 -0000 1.3
+++ pkg/DESCR 26 Feb 2013 21:36:37 -0000
@@ -6,3 +6,9 @@ The groff distribution includes:
* postprocessors for various output devices, including character
terminals, X terminals, PostScript, HTML and XHTML, and TeX DVI;
* and many utility programs.
+
+Some traditional groff companions are intentionally not pulled in
+as dependencies. For example, graphics/grap and graphics/ImageMagick
+that are needed by groff's eqn2graph, grap2graph and pic2graph
+are available as separated packages.
