guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#53908] [PATCH] Opportunities


From: Frank Pursel
Subject: [bug#53908] [PATCH] Opportunities
Date: Fri, 11 Feb 2022 13:04:15 -0800

Hi,

My intentions were good but this isn't good.  I now see that though this
ditaa package will build and work this package isn't yet ready for guix.
If you want to help advance this, read on!  I'll point out what I
perceive I missed on the first go around.  I still eventually hope to
get ditaa officially packaged for guix.  

I belatedly see that I've stumbled into some less than desirable
practices here.  So, to be quick, ditaa in guix needs to wait until the
underlying dependencies in java-batik-all-jar are under approriate build
control.

I now see that the current java-batik-all-jar build depends on the use
of several jars embedded in the apache source package.  It isn't guixy
to use these. We need to provide guix built packages to replace those
jars (some of which already exists).  If we keep ditaa as the end goal
replication of all these jars is likely not necessary (though it would
be nice); it should be possible to significantly narrow the scope of
these packages to only those required to build ditaa.

I also see that there are guix conventions that help the java/ant-build
system ecosystem better integrate.  Specifically I now see that java
libraries go into the share/java directory as a single jar file.

I still hope to get ditaa packaged for guix.  I do not think it is
important for guix but ditaa is a good example of the use of free
software to scratch an itch nobody else was going to get to (I think it
used to be packaged with emacs org mode).  I naively thought this was
clean on the first go but now I see that good guix standard requires a
little more digging into the sources.

Working on it,
Frank





reply via email to

[Prev in Thread] Current Thread [Next in Thread]