Re: r4182 - in trunk/packages/adun.app/trunk/debian: . patches

[Yavor Doganov <yavor@gnu.org>]

Andreas Tille wrote:
> I have one question when looking at the upstream tarball which has grown
> five times in size and probably one reason is the addition of
> ExternalPackages/StepTalk:

Yes, the rest is lots of new code and additional features.  Actually
StepTalk is relevantly small, the big stuff is UL/Resources/AdunHelp
(not installed and not viewable with helpviewer.app anyway).

> I see the directory in the source but neither do I see a sign that
> it is used in the build ("grep -i steptalk *.build" is empty) nor do
> I see Debian's steptalk package in the (Build-)Depends.

Right, it's not built because we currently don't build the plugins.
(One of the plugins, AdunShell, depends on StepTalk.)  But even when we
do, we will of course use the Debian steptalk package and not the
bundled one.

> If it is completely unused code we might consider stripping it from
> the source tarball.

It is and will be completely unused, but I don't think that would gain
much:

yavor@hatch:/tmp/Adun-0.81$ tar czf steptalk.tar.gz ExternalPackages; \
  du -h steptalk.tar.gz
160K  steptalk.tar.gz

>    adun.app: arch-dep-package-has-big-usr-share 4136kB 56%

Yes, I saw that too, but I think it's better to wait to see how this
will change when we start building the plugins.  Or we may separate
them in another adun.app-plugins package, so it would be the right
time to also split adun.app-common (to avoid passing throug NEW
twice).

For the plugins, the following needs to happen:

1) The Debian steptalk package should be repackaged properly as a
   shared library.

2) Adun assumes all the plugins are installed in $HOME/adun, which is
   of course not acceptable.  It is fairly straightforward to patch it
   and change the code to search for the system Bundles location, but
   I'm thinking of a more general solution that would be acceptable
   upstream (so that we don't have to carry out the patch forever, and
   for the benefit of other users too).

> So if you think the package is ready for upload just go for it.

Yes, I think it's ready.  (I can't upload, though.)