This is the mail archive of the
docbook-apps@lists.oasis-open.org
mailing list .
Re: authoritative source for SGML ISO character entitydefinitions?
- From: "Matt G." <matt_g_ at hotmail dot com>
- To: veillard at redhat dot com
- Cc: docbook-apps at lists dot oasis-open dot org
- Date: Wed, 16 Jan 2002 09:10:00 +0000
- Subject: Re: DOCBOOK-APPS: authoritative source for SGML ISO character entitydefinitions?
- Bcc:
> > >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