On Thu, Oct 28, 2004, Andreas SCHMIDT wrote: > 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. > This is very similar to what I use OpenPKG for, and a basic OpenPKG requirement from early on in the project. I think in this case OpenPKG will make your work easier, and will probably outperform other packaging utilities.
> a minor reason for using openpkg is, that although our > development-servers are completely linux-based, the production-servers > are sometimes sun-solaris machines. > With only two platforms to cover, OpenPKG only has a marginal advantage over other packaging utilities. > 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. > If using software older than 1 year is your main requirement, then OpenPKG's policy of supporting only the last two releases is a disadvantage. Here I recommend dpkg with two comments. First, you should limit your Linux platforms to Debian only and make all your own packages for the Solaris systems. Second, even the newest stable debian packages are often outdated, so you have to be happy with running relatively old software. > 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. > Those aren't all release packages, so OpenPKG does not meet this requirement. If you aren't willing to write or correct the packages yourself, then this could be a problem. Remember that if you find a SRPM (source RPM package) for any of the software you are missing, making an OpenPKG package out of it is relatively simple. > 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 are other packaging utilities for you to consider, though I expect (from your work environment explanation) that you'll find them rather unsatisfying. But lets be optimistic, and spend an afternoon installing plain RPM or dpkg on Solaris. Then the next day try building packages from source on there. You won't be able to have more than one instance on the machine, and will be missing some other OpenPKG features. I'm not sure how far you'll get with this approach, but you'll be in a good position to make the right decision. Regards, Michael -- Michael Schloh von Bennewitz <[EMAIL PROTECTED]> Development Team, Operations Northern Europe Cable & Wireless Telecommunications Services Tel +49-89-92699-227, Fax +49-89-92699-808
pgplyBIl9qUQw.pgp
Description: PGP signature
