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?
--
Paul W. Frields
http://paul.frields.org/
gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717
http://redhat.com/ - - - -
http://pfrields.fedorapeople.org/
irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug