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