On Tue, Oct 07, 2003, Anshuman Kanwar wrote:
> Hi all,
>
> I am in a situation where I am required to install a package on a machine
> multiple times in different locations on the file system. I am looking for a
> packaging system that supports the notion of a instance number in addition
> to version and release numbers. Does such a notion exist in OpenPKG ?
>
> In other words :
>
> Can I have a package doodle-i386-3.0-X.pkg and at install time provide the
> value of X ?
>
Ansh,
if you prefer a oversimplified answer: not with OpenPKG.
But lets go for some background. OpenPKG is based on RPM and technically
inherits all of its features. That doesn't mean we like to use and
support every feature RPM provides.
BINARY PACKAGES
One of the features we do not use in our project today is RPMs
"--relocate" option. This means none of our packages was ever build with
support for this option in mind. But that feature stays dormant in our
tweaked rpm and nothing will stop you from using it in your own RPM spec
files whether it is native-RPM or OpenPKG-RPM.
As far as i know the "--relocate" feature actually does two things:
installing files to a location different from the suggested path names
in the package and it provides a variable or macro INSTALLPREFIX (i
guess) to the various %(pre|post)(un) and %trigger scriptlets. Note
that many software will not work when it is just copied to a different
location. Paths to related binaries, config and data files etc. must
be adjusted in the majority of cases. This becomes especially painful
when paths are hardcoded into executables at build time which means the
installation process has to twiddle the entrails of binaries. I'm aware
of at least one project, breloc [1], which focuses on this topic.
SOURCE PACKAGES
It is a primary goal of OpenPKG to be able to create a large number
of instances on a single machine - presumed the packages are build
from source for each instance. This not only isolates OpenPKG from
the operating system but it also isolates OpenPKG instances from each
other. We spare no efforts making every package relocatable under these
conditions. We even (conditionally) replace syslog(2) so there is no
logging interference between instances. However, you have to build
binaries once for every prefix. There is absolutely no problem to run as
many sendmails, postfixes, apaches, openldaps, proftpds etc. in parallel
on a single box as long as hardware resources can keep up!
PACKAGE NAMES
The facts about binary and source packages result in a package name
scheme where source RPMs are "locationless" and binary RPMs have a
"location id tag" in their filename. This reflects our thinking of
source RPMs being relocatable and binary RPMs being already build for a
specific location which is usually not relocatable.
PROXY PACKAGES
In some cases isolating OpenPKG instances from each other is overkill
when it comes to basic software like development tools. It is often only
a waste of time and storage to build lots of gccs, m4s, perls etc. on
a single box. It is therefore possible to declare one OpenPKG instance
as a master by decree and for other instances create so called proxy
packages which are more or less only symlinks to the master.
IMPORT PACKAGE
The brand new openpkg-import extends the philosophy of proxy packages to
the operating system level by creating symlinks to selected operating
system features. Currently only MTA aka sendmail is supported but more
features could be imported.
MORE
It is worth reading the OpenPKG fact sheet [2] to understand the
philosophy and the FAQs [3] for up to date information. There is a
user tutorial [4] for the impatient and a quick reference [5] for the
curious. There is also a slide set [6] for getting an overview. And last
but no least, there's lots of documentation [7] available.
[1] http://www.bell-labs.com/nsbd/breloc.html
[2] http://www.openpkg.org/facts.html
[3] http://www.openpkg.org/faq.html
[4] http://www.openpkg.org/tutorial.html
[5] http://www.openpkg.org/doc/quickref/openpkg.txt
[6] http://www.openpkg.org/doc/slideset/openpkg.html/
[7] http://www.openpkg.org/doc.html
--
[EMAIL PROTECTED], Cable & Wireless
______________________________________________________________________
The OpenPKG Project www.openpkg.org
User Communication List [EMAIL PROTECTED]
