Publican Documentation Naming

Tom "spot" Callaway tcallawa at redhat.com
Tue Mar 31 22:14:56 UTC 2009


On 03/31/2009 06:07 PM, Paul W. Frields wrote:
> Now, that works fine for documentation too, in *that* case -- in other
> words, if you make some changes to the basic Security Guide, you would
> of course want to push out the newest Guide in all languages.  But
> here's where the subpackage use breaks down: You never see packagers
> issuing a new libfoo-devel package without libfoo changing.  And that
> can *definitely* happen in documentation.

Sure. We see this happening all the time, for bug fixes.

> For example, you could add a new, previously unused translation to
> your Guide.  Using subpackaging, in order to issue it, you'd have to
> rebuild the entire set of languages, and when you do, our build system
> -- as far as I know -- won't let you just push the one new language
> subpackage out.  It would require *all* the language subpackages to be
> reissued, even if they hadn't changed at all.

You could, but how often does this _ACTUALLY_ happen?

> Here's another twist that might make subpackages even more
> unpalatable.  It implies that there will be a *resistance* to pushing
> out translation fixes quickly.  There will be a tendency to wait
> before reissuing packages.  Subpackages may lower the workload for a
> small Docs team -- you could only issue a quarterly update, or on some
> other regular but liveable basis -- but arguably at the cost of
> friction with the translation teams.

Honestly, if this is a significant enough problem to need solving, we
should solve it with other mechanisms than overloading CVS with hundreds
of otherwise identical packages.

We could find a way for koji to build specific subpackages for
translated %doc packages. The spec files would need a set of
conditionals, and we'd need to standardize on lang variables, then build
a mechanism to pass the conditionals through to the builder.

I would prefer that mechanism, for example. I suspect that Jesse would
too (but I'm CC'ing him in case I'm wrong).

~spot




More information about the fedora-docs-list mailing list