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