Test of Docs Packaging

[Paul W. Frields]

On Fri, 2005-10-21 at 05:27 -0700, Karsten Wade wrote:
> > > > What am I missing?
> > > I'm thinking of the fact that there's no other piece of stuff in Fedora
> > > that can't be built or rebuilt entirely from a .src.rpm and assorted
> > > BuildRequires.  If someone "in the know" @RH says "Shut up, nobody
> > > cares," that's good enough for me. :-)
> > 
> > This seems empty form to me but I ain't @RH anymore.
> > 
> > I keep envisioning only two use cases:
> > 
> > 1) Developer -- eveything local from a CVS checkout, even if I don't
> > have CVS write permission.
> > 
> > 2) End user, aka read-only -- install the RPM's and yelp away.
> > 
> > What am I missing?
> 
> 3) People who want to use the FDP structure to write their own
> documentation.
> 
> They don't necessarily care a whit about our content, so CVS access and
> associated is not valuable.  Having a complete document building
> environment is.

Right, the same way that someone who doesn't care about having CVS
access to Extras or Core is able to patch and roll their own RPMs from
that content.

> I don't know that this was an FDP intention from the start, but the fact
> is people use our DocBook templates.  When we get PDF working, I expect
> we'll see that number increase, mainly because we then have the most
> complete DocBook toolchain that is also 100% free.
> 
> I think it is a good idea to have a common documentation infrastructure
> RPM that is separate from the content packages.  Interacting like this?
> 
> 1. Document package, foo-en.rpm -- stand-alone, has all build targets
> and copy of XML for Yelp et al.
> 
> 2. Document source package, foo-en.src.rpm -- requires doc
> infrastructure package to build, this package is mainly XML, Makefile,
> and images.
> 
> 3. Document infrastructure package -- all that you need to build one of
> the .src.rpms, to roll your own docs packages, or to roll your own
> documentation set.
> 
> > Quaid? Final answer?
> 
> As long as I have addressed every point?  I do think I have.

I thought originally that fedora-doc-common-<ver>.noarch.rpm might
provide this (all other RPMs would have a BuildRequires pointing
thereto) but I am not sure if that's appropriate, or whether we should
have a separate fedora-doc-devel RPM instead.  The difference would be
that f-d-common would include content files that are shared by all
installed documents, whereas f-d-devel would package build components
that are not used outside the building process.  I don't know where to
draw that line.  But I can see that this line of thinking might shift
our process subtly.

For instance, it might open the process a bit to automation, in the same
way that the brilliant plague/buildsys component has in Fedora Extras.
Rather than asking for CVS access, people could "yum install
fedora-doc-devel" and use our toolchain to build their own doc sets the
way Karsten described, or they might use them for drafting, only
applying for CVS when it was comfortable.

I'm not sure I can fully articulate how/if this is better than what
we're doing currently.  Any ideas?

-- 
Paul W. Frields, RHCE                          http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-docs-list/attachments/20051021/c692db21/attachment.sig>