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

Re: Splitting package xmlto - which way is better?

On Mon, 2008-07-14 at 13:32 +0200, =?ISO-8859-1?Q?Ond=3Fej_Va=3F=EDk_
> Hello,
> I would like to ask you about splitting package xmlto.
> I got request to split xmlto package to throw away passivetex (and TeX)
> requirements in the case of xmlto usage for building txt/html
> documentation (rhbz #454341). This change is reasonable, but I'm not
> sure which way is better. Generally I have two possibilities:
> 1) Split to xmlto and xmlto-base - with xmlto Requires: xmlto-base . In
> xmlto-base all binaries, documentation and backends without passivetex
> requirements. Main package will contain only three backends (fo to
> dvi/ps/pdf) after that change. This will not break any builds in Fedora
> Rawhide but raises rpmlint warnings about no binary/documentation in
> main package.
> 2) Split to xmlto and xmlto-tex . This will break builds which are using
> xmlto for building pdf/ps/dvi documentation - additional BuildRequires
> for xmlto-tex backends subpackage will be required. 
> Which one should be preferred?
> I like the possibility #1 a bit more, although I guess in long-term is
> #2 better solution. Any other ideas?

I think #2 is definitely the better way to go.  The passivetex stuff for
building the PDF format, in my experience, has been fragile at best for
some time.  Although fop is getting closer to usable, and could end up
being used by the xmlto scripts for PDF building in the future, it's not
there yet -- and when it is, the fop package will also drag in a lot of
Java package deps.

Paul W. Frields
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
  http://paul.frields.org/   -  -   http://pfrields.fedorapeople.org/
  irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug

Attachment: signature.asc
Description: This is a digitally signed message part

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