On Thu, Oct 28, 2004, Andreas Schmidt wrote:
> [...]
> we are developing web applications, mostly based on software like java
> (j2ee), apache, db-servers, ldap-servers in various combinations and
> configurations.
Well, right after mentioning things like Java and Apache2 it becomes
immediately clear to me that OpenPKG will not solve your problems
out-of-the-box ;-)
Sorry for this, but during the last years, neither Java nor Apache2 were
ever of any major importance to us (Java is not really Open Source and
nasty to package because mainly a binary distribution which doesn't fit
with OpenPKG's "from-source" approach and Apache2 is... well, Apache1 is
sufficiently nasty and I know Apache1 well enough ;-). So, it is clear
that those products are not as well packaged and tested as others. At
least not until somebody helps out and polishes them.
You also can see this by looking ("openpkg rpm -qpi") at the "Group" RPM
header of those packages: they are of class EVAL or maximum PLUS since a
long time which means that they are not in the focus of one of the core
OpenPKG developers.
> [...]
> a minor reason for using openpkg is, that although our
> development-servers are completely linux-based, the production-servers
> are sometimes sun-solaris machines.
"Minor reason"? Ops, I'm surprised. At least most of the administrators
I know of count the possibility to easily reproduce 1:1 a development
environment on a production machine a _major_ reason. But ok, no offence
here, everyone has its own priorities...
> [...]
> in practice, i have the problem, that we have a lot of legacy-projects,
> sometimes with very old software-versions. and even in new projects, we
> often can't decide, which version of a specific package we have to use.
> so we must be able to build specific releases of the various packages,
> not only the one, distributed with the openpkg instance. maybe it would
> be possible to get source-rpm for older versions from the cvs, but is
> there a guarantee, that a source-rpm of openpkg 1.2 will run in an
> openpkg 2.2 instance?
No, but unfortunately this guarrantee you also will _not_ get from _any_
software distribution. It's a general problem in the software business.
At least all Unix software distributions I know of allow you to mix
releases only to some limited extend.
And most of the time it is not really the fault of the distributions,
but just a nasty side-effects of the fast and independently evolving
vendor versions. You cannot expect e.g. to run an old Linux program
without problems under the latest Linux kernel and GNU C library (and
vice versa). Most of the time it will already fail to start because of
incompatible ABIs and fail to recompile because of incompatible APIs.
> my first experience in building older apache
> versions from apaches src.tar.gz ends in coredumps.
Yes, that's why software distributions create "releases" where all
components fit together. Mixing software from different releases
inherently fails, although for the really portable products it works
to some extend. Unfortunately most products are not portable and
self-adjustment enough.
> [...]
> second: java-web application-environments doesn't seem to be a major
> focus of the openpkg-community. trying to build a really basic and
> common configuration with apache2, tomcat4 and mod_jk-connector with the
> current release didn't succeed. i wouldn't expect this, if more people
> out there were using openpkg for this kind of stuff. so, if this is my
> primary focus, i would have to dig deep into openpkg before being able
> to use it.
Yes, your ultimate problem is that you need a combination of two
products where each of them already is not well packaged and tested. It
is clear that this has to fail inherently.
> [...]
> so, what is your opinion? is it worth for me, to dig deeper into
> openpkg, because there's a light at the end of the tunnel. or do i
> expect things, that openpkg can't deliver (now)?
> [...]
I think it is as simple as it can be for any type of technology: OpenPKG
solves a bunch of problems and causes some others. Whether it is worth
the effort for you depends on the balance. If OpenPKG currently makes
you more problems than it helps you and you cannot afford helping out
here to change this for your own near future, do not waste your time
and forget OpenPKG immediately and go a different direction. If you are
convinced that once you solved your current problems with OpenPKG it
will help you _multiple_ times in the future, stay with us and help out.
OpenPKG is a tool, nothing more. If it still doesn't help you solving
the problem, either fix it or throw it away.
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
______________________________________________________________________
The OpenPKG Project www.openpkg.org
User Communication List [EMAIL PROTECTED]
