Packaging asciidoctor-pdf

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Packaging asciidoctor-pdf

Keith Packard

With the deprecation of asciidoc, I'm trying to move documentation to
asciidoctor. However, the pdf generation path for that tool,
asciidoctor-pdf, is not packaged for debian. Of course, attempts to
package that end in the usual yak-shaving exercise of packaging all of
the dependencies. These are:

        prawn-icon
        prawn-svg
        prawn-templates

The only dependency I was unable to create a debian package for with
gem2deb is prawn-templates which is a little package that contains code
extracted from prawn 0.12 and carried forward to support newer versions
(more or less). It replaces some files from ruby-pdf-core with ones
which seem pretty incompatible. I've worked around that by just not
using this package; it makes asciidoctor-pdf unable to use .pdf files as
images in the resulting output; a restriction I can live with for now.

I've pushed debian packaging for prawn-icon, prawn-svg and
asciidoctor-pdf to:

        https://salsa.debian.org/keithp/ruby-prawn-icon
        https://salsa.debian.org/keithp/ruby-prawn-svg
        https://salsa.debian.org/keithp/asciidoctor-pdf

These have corrected copyright files and have disabled the rake tests as
those didn't work for me, plus the prawn-icon and asciidoctor-pdf
packages install a pile of data files to /usr/lib/ruby/data.

--
-keith

signature.asc (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Packaging asciidoctor-pdf

Antonio Terceiro-3
Hello Keith,

You didn't explicitly ask anything, but I'm assuming you want an opinion
on the packages. :-)

also, CC:ing you explicitly as I'm not sure you are subscribed. let me
know if that's not necessary

On Thu, Nov 01, 2018 at 09:28:21PM -0700, "Keith Packard" wrote:

>
> With the deprecation of asciidoc, I'm trying to move documentation to
> asciidoctor. However, the pdf generation path for that tool,
> asciidoctor-pdf, is not packaged for debian. Of course, attempts to
> package that end in the usual yak-shaving exercise of packaging all of
> the dependencies. These are:
>
>         prawn-icon
>         prawn-svg
>         prawn-templates
>
> The only dependency I was unable to create a debian package for with
> gem2deb is prawn-templates which is a little package that contains code
> extracted from prawn 0.12 and carried forward to support newer versions
> (more or less). It replaces some files from ruby-pdf-core with ones
> which seem pretty incompatible. I've worked around that by just not
> using this package; it makes asciidoctor-pdf unable to use .pdf files as
> images in the resulting output; a restriction I can live with for now.
>
> I've pushed debian packaging for prawn-icon, prawn-svg and
> asciidoctor-pdf to:
>
>         https://salsa.debian.org/keithp/ruby-prawn-icon
>         https://salsa.debian.org/keithp/ruby-prawn-svg
>         https://salsa.debian.org/keithp/asciidoctor-pdf
>
> These have corrected copyright files and have disabled the rake tests as
> those didn't work for me, plus the prawn-icon and asciidoctor-pdf
> packages install a pile of data files to /usr/lib/ruby/data.
Disclaimer: I gave only a quick look at the first package.

No packages use /usr/lib/ruby/data so far; we usually use
/usr/share/$package for data, but this usually requires some patching.

Another alternative that almost always does not require patching since
it follow an installation layout that matches what upstream assumes, is
to use the "rubygems" installation option¹, in which all Ruby code and
associated data is installed under a package-specific directory in
/usr/share/rubygems-integration/.

¹ `export DH_RUBY = --gem-install` in debian/rules

Also, I noticed that you are using the upstream git repository directly
with the Debian packaging in a git branch. I checked debian/control and
it has the Ruby team in Maintainer:. I personally find it nice and
practical to follow upstream git, but if you want to put these packages
for the team, it would be nice to be consistent with the rest of the
team packages and use the same structure: git-buildpackage, with
upstream source imported from tarballs and pristine-tar (i.e. the
standard git-buildpackage workflow)

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Packaging asciidoctor-pdf

Keith Packard
Antonio Terceiro <[hidden email]> writes:

> Hello Keith,
>
> You didn't explicitly ask anything, but I'm assuming you want an opinion
> on the packages. :-)

Indeed!

> also, CC:ing you explicitly as I'm not sure you are subscribed. let me
> know if that's not necessary

Thanks, I'd like to avoid subscribing if possible.

> Disclaimer: I gave only a quick look at the first package.
>
> No packages use /usr/lib/ruby/data so far; we usually use
> /usr/share/$package for data, but this usually requires some patching.

Thanks, I'll patch that; I'm already having to patch asciidoctor-pdf to
avoid using prawn-template, which looks like a nightmare and doesn't
appear to be package-able at all.

I have gotten a patch into asciidoctor-pdf, so I may start seeing what
their schedule for replacing prawn-template is.

> Another alternative that almost always does not require patching since
> it follow an installation layout that matches what upstream assumes, is
> to use the "rubygems" installation option¹, in which all Ruby code and
> associated data is installed under a package-specific directory in
> /usr/share/rubygems-integration/.
>
> ¹ `export DH_RUBY = --gem-install` in debian/rules

Yeah, I'd rather be more compatible with the 'normal' debian locations;
I packaged these quickly as there doesn't appear to be a credible
asciidoc to pdf option in debian at this point, and I need it.

> Also, I noticed that you are using the upstream git repository directly
> with the Debian packaging in a git branch. I checked debian/control and
> it has the Ruby team in Maintainer:. I personally find it nice and
> practical to follow upstream git, but if you want to put these packages
> for the team, it would be nice to be consistent with the rest of the
> team packages and use the same structure: git-buildpackage, with
> upstream source imported from tarballs and pristine-tar (i.e. the
> standard git-buildpackage workflow)

I haven't ever managed to make that work, but if that's what you want, I
guess I'll go learn something new...

Thanks much for your review; it looks like I've got only a couple of
things to fix. With asciidoc being deprecated in policy, it seems
somewhat pressing to migrate to asciidoctor-pdf, which means getting
that packaged and into the repo.

I'll post another note when I've fixed the above issues.

--
-keith

signature.asc (847 bytes) Download Attachment