On Thu, Nov 02, 2006, Yann Fuselier wrote:
> I'm running openpkg release 2.20060622 on a platform ix86-solaris10.
>
> I install apache-1.3.37-20060818 from source package.
> In the directory /openpkg/RPM/SRC/apache, I change apache.spec and apache.conf
> configuration files according to my needs.
> Then, I compile the package with command : openpkg rpm -bb ./apache.spec
> I install the binary package just made, start apache and all is working well.
>
> Then, I would like to upgrade to the last version of apache :
> apache-1.3.37-20060920.
> So, I execute the command : openpkg build -U apache | sh
> This command does the following job :
> - installed the new sources of apache.
> - compile apache with the same "spec"
> - install the new binary package but OVERWRITE without any backup my
> configuration file /openpkg/etc/apache/apache.conf with the default one.
> - restart apache.
>
> To keep my configuration file, I can make by myself a backup before starting
> upgrading. But, why the command build doesn't save the configuration file
> before or keep the runnning one ?
Well, the problem you are faced with is a subtle one: you have not
changed the /openpkg/etc/apache/apache.conf _after_ installation of the
"apache" package, but you changed it already in the package.
As a result OpenPKG RPM remembers in its RPM DB that the installed
apache.conf is still _unchanged_ (from the point of view of difference
against the original file in the binary package). So, when you upgrade
to a newer package, OpenPKG RPM thinks there was no _user_ change and
hence happily upgrades apache.spec from the old _vendor_ version (the
version in _your_ binary package) to the new _vendor_ version (the
version in _our_ binary package).
So, one either has to use the original packages and make changes
directly to the installed files (this way OpenPKG RPM is smart enough
and preserves your changes as long as no change in the vendor version
happens) or you have to _KEEP_ your "change source packages" approach
(which means you _have_ to reapply your changes every time). One cannot
mix the two approaches.
Usually one directly changes configuration files. This works fine if
you have just a couple of instances where you need this change. If you
really need this change across a large number of instances, you have to
_MAINTAIN_ your own version of the packages. But this is usually not
done by installing a source RPM, changing files and rolling a binary RPM
directly in the target instance. Instead one uses the CVS based "openpkg
dev" environment as only this way one is able to maintain the package
over a longer time by merging the own changes and our upstream changes.
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
______________________________________________________________________
The OpenPKG Project www.openpkg.org
User Communication List openpkg-users@openpkg.org
