GNU bug report logs - #76926
31.0.50; Hyperbole tarball bloat

Previous Next

Full log

Message #10 received at 76926 <at> debbugs.gnu.org (full text, mbox):

From: Mats Lidell <matsl <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Robert Weiner <rsw <at> gnu.org>, 76926 <at> debbugs.gnu.org
Subject: Re: bug#76926: 31.0.50; Hyperbole tarball bloat
Date: Mon, 10 Mar 2025 22:12:52 +0100

Hi Stefan,

> Stefan Monnier writes:
> Package: Emacs
> Version: 31.0.50
>
>
> The current Hyperbole code is a bit less than 3MB of ELisp code, but the
> resulting tarball in GNU ELPA is more than 20MB.
>
> Skipping the worst offenders
>
>     *.eps
>     *.pdf
>     *.html
>     HY-TALK/improve-performance.png
>     man/im/wgrid4x3.png
>
> would bring it down to about a third of the current size, but I suggest
> you think about which of the files in the Git could be skipped in the
> tarball (e.g. because they're only useful for the website) or even
> completely removed from Git (like `man/im/wgrid[34]*.png` files which
> don't seem to be used for anything, or the non-source files like
> `hyperbole.pdf` or the `.eps` files which could be replaced by
> appropriate Makefile rules).

Point taken. We'll see how we can clean git from big files.

The tarball is built with the idea that users would get everything needed
without having any extra tools nor to be required to run any make
targets. That might be an old fashioned goal these days and users are bettered
served by fetching things from the net. Especially if we already provide those
through different channels.

> There's no point skipping small files, so usually I encourage package
> maintainers to include pretty much everything, but here I think we went
> a bit overboard.

> On a related note, have you tried to use `x-export-frames` to generate
> screenshots in PDF or SVG format?  It might (should?) lead to images
> that are more compact than `wgrid4x3.png` while giving a higher quality
> rendering.

No, we have not tried that. I did not know that was available. Thanks for the
suggestion.  (So many things in Emacs I learn new stuff every day ;-) I will
take a look what can be done about the images. They might need regeneration
anyway with next release due to things have changed since we produced them. We
can try to make them more compact when we update them.

> Also, I see there's a `man/hyperbole.texi` but the current package's
> spec doesn't specify any manual.  I guess we should add
>
>     :doc "man/hyperbole.texi"
>
> right? [ That would auto-generate `hyperbole.info` and `dir` files so
> users who install your packages get it in `M-x info`, as well as add an
> HTML rendering of that same manual over at
> https://elpa.gnu.org/packages/hyperbole.html.  You don't need to
> include `hyperbole.html` and `dir` and `hyperbole.info` in the Git for that.  ]

I think our current solution also works in making Hyperbole available in
info. But if we can get the necessary files generated, using the standard
machinery, there would be less to ship. Thanks for the suggestion.

Yours
-- 
%% Mats

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.