Re: DOCBOOK-APPS: authoritative source for SGML ISO character entitydefinitions?

["Matt G." <matt_g_ at hotmail dot com>]

> > >Really, the linux tools (RPMs from say, redhat, Mandrake et. al)
> > >are getting to the point where they provide a good environment
> > >for docbook processing "out of the box".
> >
> > Thanks, but I'm not really interested in packages.  To properly
> > maintain an industrial-strength installation, it is ideal to be
> > able to obtain and upgrade each component, independently.  ...and
> > I don't want to grab entire kits, simply for the sake of one
> > particular component.
>
>   Then please don't complain about the complexity of the setup on
>the application list.

I didn't.  I have been *responding* to people who were complaining about the 
complexity of setup.  If I did, then I must be suffering from a short-term 
memory lapse, so I'd appreciate it if you could direct me to a specific 
example.


IMO, packages are good.  They suit most people's needs.  I think I've said 
this repeatedly.

However, now that we're on the subject, I think everyone would agree that 
DocBook deployment is harder than it needs to be.  Part of the problem is 
things like outdated/incomplete documentation that's included with core 
tools, like OpenJade.  Packaging can shield most people from this, but it 
really is only a band-aid solution, rather than solving the problem at its 
source.

Another problem is that people are trying to use bleeding-edge packages, 
like some parts of the XSL-FO toolchain, without realizing how immature they 
are (IMO, packaging is a more appropriate solution, for this).


>If you deliberately opted for the hard way and doing everything by
>yourself, then you should not complain that there is work down the

I deliberately opted for "the hard way", because manageability (and 
symmetry, across platforms) was extremely important to us.  From the outset, 
I was fully aware of the tradeoff that it takes more work, to do it that 
way.


>road. Some things like for example maintaining catalogs etc...
>can be really easy when packaging is present and a real nightmare
>when you're doing the install without any underlying structure.

I'm a big boy; I can hack it.  However, that's not to say that I won't 
attempt to discuss strategies various people use, for managing such things.  
For, you see, while black box is good for most users, it won't suit 
everyone's needs, and in case it doesn't, it's useful to have sufficient 
information archived, so that people can piece together their own solutions 
or packages.


> > Furthermore, our environment consists of about a hundred Linux +
> > Solaris + FreeBSD boxes, and everything must be installed on the
> > network, in a reproducible fashion, so RPMs tend to be pretty
> > useless.
>
><offtopic>
>    seems you didn't looked very far. RPMs and other packages are
>    working on those.
></offtopic>

I'm no sysadmin (I didn't want to take on the task of maintaining these 
tools, but there was no one else who'd take it seriously or had time), but I 
was under the impression that RPMs are often not only OS-specific, but also 
specific to the version of a particular OS.  With properly 
Automake/Autoconf'd packages, it's very little work for me to write a 
script, for each version of each package, to build and install it on any 
version of any OS we do and will use.  We use so many packages (some are 
custom-patched, too), that we can't afford to rebuild /usr/local/ by hand, 
every time we upgrade an OS to a new version.  Furthermore, the entire model 
that tools like RPMs seem to be based on is that you have only one version 
of a given package installed on a given system, at a given time, which is a 
model we do *not* follow, for packages that aren't extremely mature.  In 
other words, when I install OpenJade 1.3, it must be built and installed (in 
/usr/local/openjade-1.3/) on every version of every OS we use, until 
business conditions change enough that any previous releases of any products 
which include a component in which OpenJade 1.3 was involved in building has 
been de-supported.  The reason it must be possible for us to exactly 
reproduce a build of /usr/local/ is that we require symmetry across all 
versions of all OSes we use, so that the products of our engineering group 
aren't coupled to these things, in any way.

Maybe I have some mistaken ideas about RPMs (my apologies, if so), but it's 
my understanding that they aren't designed to satisfy the above usage model. 
  Regardless of that, I doubt they'd save me much time, even if they could 
be used as described, above.


However, if I want to upgrade the version of Mozilla I'm running, on my 
desktop, for example, of course I use the RPM.


Matt Gruenke


_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com