Hey Guys,
I was looking through the packages.py code at the installation code and noticed this piece of code
rpm.addMacro("__dbi_htconfig", "hash nofsync %{__dbi_other} %{__dbi_perms}")
I was wondering if someone could explain what that does for the installation process ?
TIA,
On Tue, 2004-08-24 at 16:34 +0100, Glen Gray wrote:
I was looking through the packages.py code at the installation code and noticed this piece of code
rpm.addMacro("__dbi_htconfig", "hash nofsync %{__dbi_other} %{__dbi_perms}")
I was wondering if someone could explain what that does for the installation process ?
It speeds things up by changing some of the properties of the Berkeley DB access. It's a little bit less safe in case of power failure or weird things like that, but at the same time, if you get a power failure during install, you're going to have other large problems anyway :)
Jeremy
On Tue, 2004-08-24 at 17:20, Jeremy Katz wrote:
rpm.addMacro("__dbi_htconfig", "hash nofsync %{__dbi_other} %{__dbi_perms}")
It speeds things up by changing some of the properties of the Berkeley DB access. It's a little bit less safe in case of power failure or weird things like that, but at the same time, if you get a power failure during install, you're going to have other large problems anyway :)
As I suspected. Thanks for the confirmation.
Hmmm, there's no way to pass something like that via the command line is there ? I guess the appropriate thing would be to set it in the /etc/rpm/macros or ~/.rpmmacros. I'll give that a go and see if it speeds up my installation script.
Thanks again.
On Tue, 2004-08-24 at 17:20, Jeremy Katz wrote:
rpm.addMacro("__dbi_htconfig", "hash nofsync %{__dbi_other} %{__dbi_perms}")
It speeds things up by changing some of the properties of the Berkeley DB access. It's a little bit less safe in case of power failure or weird things like that, but at the same time, if you get a power failure during install, you're going to have other large problems anyway :)
Wondering if this "__dbi_htconfig hash nofsync %{__dbi_other} %{__dbi_perms}" is the correct format to use when putting it into /etc/rpm/macros ?
TIA,
On Wed, 2004-08-25 at 08:37 +0100, Glen Gray wrote:
On Tue, 2004-08-24 at 17:20, Jeremy Katz wrote:
rpm.addMacro("__dbi_htconfig", "hash nofsync %{__dbi_other} %{__dbi_perms}")
It speeds things up by changing some of the properties of the Berkeley DB access. It's a little bit less safe in case of power failure or weird things like that, but at the same time, if you get a power failure during install, you're going to have other large problems anyway :)
Wondering if this "__dbi_htconfig hash nofsync %{__dbi_other} %{__dbi_perms}" is the correct format to use when putting it into /etc/rpm/macros ?
For /etc/rpm/macros, you have to do %__dbi_htconfig hash nofscyn %{__dbi_other} %{__dbi_perms}
instead
Cheers,
Jeremy
On Wed, 2004-08-25 at 15:28, Jeremy Katz wrote:
For /etc/rpm/macros, you have to do %__dbi_htconfig hash nofscyn %{__dbi_other} %{__dbi_perms}
As in purposefully misspell the sync part to nofscyn or just don't use the quotes (hadn't intended to).
I added it as above (with correct spelling) and I'm not sure I noticed a difference. Still takes about 33 mins to do a full workstation install. Which isn't bad I suppose. I have yet to take a large knife to the package list.
Cheers,
On Wed, 2004-08-25 at 16:09 +0100, Glen Gray wrote:
On Wed, 2004-08-25 at 15:28, Jeremy Katz wrote:
For /etc/rpm/macros, you have to do %__dbi_htconfig hash nofscyn %{__dbi_other} %{__dbi_perms}
As in purposefully misspell the sync part to nofscyn or just don't use the quotes (hadn't intended to).
Don't use the quotes and put the % at the beginning. Macros have to be defined as %macro in /etc/rpm/macros and then rpm strips off the leading % before passing to addMacro
Jeremy
On Wed, 2004-08-25 at 16:15, Jeremy Katz wrote:
Don't use the quotes and put the % at the beginning. Macros have to be defined as %macro in /etc/rpm/macros and then rpm strips off the leading % before passing to addMacro
Thanks Jeremy,
I didn't have the % at the start so I'll try again in the morning.
Thanks again for the help,
anaconda-devel@lists.stg.fedoraproject.org