On Tue, Mar 31, 2009 at 06:14:56PM -0400, Tom spot Callaway wrote:
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.
Really? People issue a libfoo-devel-1.0-2 package without a concomitant libfoo-1.0-2 package?
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?
I can tell you this happens VERY often, IME in Fedora Docs.
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.
Wait, are these identical? AIUI the SRPMs contain different language content. The en-US SRPM has en-US DocBook XML content, the de-DE SRPM has de-DE DocBook XML content, etc.
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).
In which case we're back to being stuck when we try to push those spec changes back upstream to Publican, right?