[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Publican Documentation Naming



On 03/31/2009 09:12 PM, Paul W. Frields wrote:
> 
> Really?  People issue a libfoo-devel-1.0-2 package without a
> concomitant libfoo-1.0-2 package?

Concomitant? No. But with changes that only affect libfoo-devel? Yes.

> 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.

They are identical, with the exception of the "output language". More to
the point, the hundreds of spec files would be identical.

>> > 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?

I wouldn't say "stuck". The changes should be reasonably minimal. I gave
this some thought last night, and it might be something that could be
implemented along with a semi-longstanding feature request with koji:
the ability to pass specific --with or --without options through to the
build task. Each lang could be a --with or --without as needed. With
some Makefile.common love, it could be as easy as:

make build WITHOUT="en de fr cz" WITH="es"

Also, if we're "stuck" on a tool where we are in fear to make changes to
improve it or fix bugs, how open source is that tool?

I seriously doubt the package committee would endorse an approach that
throws hundreds of documentation packages (different only in
translation) at the review system, nor do I think it is likely that they
would vote to approve guidelines that enables all of these individual
packages to be reviewed in one ticket. However, that is just my opinion,
and you're certainly welcome to draft a formal proposal.

~spot


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]