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