Just looking for suggestions on:
1. Naming the root dir of an openpkg installation?
I was initially considering something like <DIR>/opkg/<VERSION> with a
symlink to it, such as <DIR>/opkg/prod
e.g. $root = /opt/opkg/1.2
/opt/opkg/prod -> /opt/opkg/1.2
However, if it's safe to assume 1.x version will be easily upgradeable
across 1.1, 1.2, etc., then I could use something like:
$root = /opt/opkg/1.x
/opt/opkg/prod -> /opt/opkg/1.x
The reasons I wanted to create another level of indirection are to:
- be able to group multiple openpkg instances in an intuitive
location (e.g. /opt/opkg/1.2-projectfoo, /opt/opkg/1.2-test )
- allow for versioning so new openpkg releases can be tested
side-by-side with a known good build if needed.
- in general, in a production environment, provide greater
flexibility as our experience with openpkg matures.
So, I'd like feedback on:
- whether the above is a concern in your environment?
- how you handle upgrades
- what your experience has been upgrading from 1.1 to 1.2 in
a production environment (ideally with 100+ machines)
2. Customized rpm naming
What's a good scheme to name a customized version of a src.rpm/binary rpm
? For example, if I change the default build options in the spec file for
apache, and create a new apache*src.rpm, I would like to distinguish it
from the original src.rpm/binary rpm before and after installation. How do
people on this mailing list handle this?
Thanks,
--
Vinod
______________________________________________________________________
The OpenPKG Project www.openpkg.org
User Communication List [EMAIL PROTECTED]
