[bug#60976] [PATCH] gnu: Add ditaa.

[Frank Pursel]

> On Tuesday 24 Jan 2023 at 0435 PST, Simon Tournier wrote:
> Why a new file?
> Could you split this commit?  Basically, each package addition should go
> to their own commit.

Yes, I puzzled over that too and I think this is the best answer.  If
you don't admit a new file (for which I don't see great economy) then
you must decide what three others you would dilute or adjust to avoid
clearly identifying the relationship between these three packages.    

There seem to be prior examples of small, unique packages of about
this size having separate files.  Ditaa creates graphics but does not
do anything like provide OS level interfaces like in 'graphics.scm'.
Similarly, it does not deal with computer science graphs like in
'graph.scm'.  It seems to me it is more like curl which stands alone
in curl.scm or bison, in bison.scm, cmake, cpio, abiword, and I could go on.
While, I know, ditaa is not as fundamental as these other giants it
shares that ubiquity.  So, I think, ditaa's uniqueness merits that
distinction.  Together with it's odd dependencies I don't see a better
fit but if someone has the courage to positively assert where each of
these packages fits I'm completely supportive.

> Why not some of the gnu/packages/java-*.scm files?  Or gnu/packages/batik.scm

Another reason not to want to split this commit is because, per the
reference manual, It seemed to me that this was also 'one set of
related changes' enabling ditaa.  java-libbatik and java-jericho-html
are unlikely to be used in support of anything else but cannot be
commited separately without breaking ditaa.  I also suspect their
purpose would quickly become unclear if mixed with other java
packages.

If there were another application that also built upon the concrete
java-libbatik then I think the argument for moving it into batik.scm
would be stronger but don't think there is one because batik.scm
remains more abstract.  I think that is ok.  'batik.scm' is java
internally uses an svg api but ditaa leverages svg to produce other
than svg output and is independent of java.  It is a tool that
is likely to be used in non-java environments.

> Please provide a comment why the tests are disabled.  For example, if
> there is no test suite or if upstream does not provide tests,

Knowing that ditaa's checks (which depend upon libbatik) was enough
for me but I think I can do better.  I'll get another patch together
to achieve this.

Noting that the qa checks on this patch now indicate that this patch is
successful (I never take this for granted) does this seem like a good
path forward?

Regards,
Frank