On Thu, 2004-10-28 at 05:26, Andreas Schmidt wrote:
> hi openpkg-users,

Hi.

> 
> after evaluation openpkg for some time my initial enthusiasm starts 
> turning into light frustration, because each step i go further, new 
> problems occur that throw me back two steps.

I had this phase in my learning process as well.  I went back and forth
between other potential packaging products but in the end I made it past
this phase because I determined that the pros by far outweighed the
cons.  I think it's merely a matter of accepting how "They" (as in the
openpkg folks here) develop and use OpenPKG themselves and not trying to
mold it into something else that perhaps you're comfortable with at the
moment.  Instead learn to be comfortable with how OpenPKG functions and
work with that.  At least that was my learning experiences initially.

> 
> with this email, i would like to explain to you, how i planed to use 
> openpkg, and would be glad, if you could give me your opinion, if 
> openpkg can really help me in making my job easier. it's a quite long 
> email, but it takes some lines, so describe my expectations and problems.
> 
> we are developing web applications, mostly based on software like java 
> (j2ee), apache, db-servers, ldap-servers in various combinations and 
> configurations.
> 
> the task: since there are a lot of projects to handle we need shared 
> development- and test-servers for our projects. i want to use openpkg to 
> completely separate the projects on the machine. each project gets it's 
> own openpkg instance. a "central" instance is used for some uncritical 
> "proxied" general purpose-packages.

It sounds more like you should just use UML. 
(http://user-mode-linux.sourceforge.net/UserModeLinux-HOWTO.html)

> 
> there are two primary reasons for me to use openpkg this way:
> -easy handling of different versions of a package on one machine
> -easy switching on/off all components of an instance
> 
> the latter is important, because we have only a limited number of 
> "active projects", that should get the machines resources, but a lot of 
> sleeping-support-project, that should not get any resources, unless a 
> client calls with a problem. then we need to be able to "switch on" the 
> whole project very quickly and without interfering other running projects.
> 
> a minor reason for using openpkg is, that although our 
> development-servers are completely linux-based, the production-servers 
> are sometimes sun-solaris machines.

Hmmm.  It can be dangerous to allow developers to do their development
on a platform/architecture which is not identical to what exists in
production.  In general, there usually won't be problems, however it's
still feasible and common in my experience for problems to occur.  Just
a side note.
 
> 
> openpkg promises seemed to fit perfect for this job -- at first.
> 
> 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? my first experience in building older apache 
> versions from apaches src.tar.gz ends in coredumps. for me, it's 
> difficult enough to build everything from source (not with openpkg- that 
> runs smooth, but with regular source distributions). but if i have to 
> expect additional problems because i'm using openpkg, this makes my 
> world darker, not lighter.
> 
> 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.

It all comes down to learning how to build rpms, customize spec files
and using the options.  It's a lot of work in the forefront, but once
you're done the efforts pay off greatly.  The maintenance of the rpms is
really simple.  That is the ultimate reward or benefits for using
OpenPKG.  Lowing overall maintenance cost.

> 
> third: this is just a minor issue, but it seems, that the concept of 
> proxy-packages isn't used very much too. otherwise, maybe, since disk 
> space is cheap, that's no critical problem, but for easy administration 
> of often used packages, it would help prevent some boring work.
> 
> i'm not shure, whether i did just miss the right way to use openpkg. but 
> i didn't find one.
> 
> 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)?

There is a light at the end of the tunnel, however if you're needs are
to simply have different environments for the same sort of application
configuration, perhaps it would be better for you to use something like
UML.  Even Solaris 10 will have a UML functionality builtin.

> 
> don't get me wrong. openpkg has an impressing concept, and i'm sure, 
> there are many environments, where it really solves problems. but i'm 
> not sure, if does it for me.
> 
> of course i know, that openpkg is open source and lives from 
> get-and-give. and i would be glad to support the project on my way 
> getting more experienced. but if i would have to get an openpkg-pro 
> first, before being able to solve my basic tasks (like installing 
> apache2-tomcat4-mod_jk), i prefer fiddling with my old problems instead 
> of getting additional new ones.
> 
> or maybe, the expected "average openpkg user" is higher qualified than 
> me -- i'm no experienced rpm-administrator, building easily .spec-files 
> and produce patches. till now it was sufficient for my job to get the 
> necessary packages and find the right ./configure options.
> 
> i'm looking forward reading your replies. thanks in advance,
>       andi
> 
> ______________________________________________________________________
> The OpenPKG Project                                    www.openpkg.org
> User Communication List                      [EMAIL PROTECTED]
-- 
David M. Fetter - UNIX Systems Administrator
Portland State University - www.oit.pdx.edu
"Only those who attempt the absurd can achieve the impossible."

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to