On Sat, Jul 28, 2007, Jeff Johnson wrote:
Ohh, well, yes, seems like I've suppressed this experience ;-)
As long as you are careful and not create new symlinks in the CVS
repository everything should be still fine...
OK. Just to get warmed up, I dragged track et al onto rpm5.org
with
On Sun, Jul 29, 2007, Ralf S. Engelschall wrote:
[...]
Thanks for all your efforts, Jeff.
But unfortunately, although this procedure correctly upgraded db/
subdir content, you missed to append the corresponding entries to
CVSROOT/history! This way the CVSTrac frontend and the CVS backend
On Sunday, 29. July 2007 at 1:11 am, Jeff Johnson wrote:
On Jul 28, 2007, at 4:49 PM, Thomas Lotterer wrote:
I want to suggest we create and maintain a document describing
architectural decisions of rpm5.org.
OK. There's nothing stopping anyone from doing whatever,
Yep. In fact,
On Sun, Jul 29, 2007, Ralf S. Engelschall wrote:
On Sun, Jul 29, 2007, Ralf S. Engelschall wrote:
[...]
Thanks for all your efforts, Jeff.
But unfortunately, although this procedure correctly upgraded db/
subdir content, you missed to append the corresponding entries to
Not setting the return code from pthread_mutexattr_setrobust_np()
is likely the fix for interoperability with glibc/kernel that does not
support robust mutexes but does define EOWNERDEAD:
+#if defined(EOWNERDEAD)
RET_SET((pthread_mutexattr_init(mutexattr)), ret);
+
On Jul 29, 2007, at 11:42 AM, Ralf S. Engelschall wrote:
Jeff, can you investigate on this remaining issue, please?
Already investigated.
Guaranteeing that a rpmdb is closed gracefully under all possible
conditions is a fool's implementation.
Consider segfaults, kill -9, reboot, more.
| $ /tmp/rpm/bin/rpm -e gpg-pubkey-2039b291-3dbaae72
| error: ^2039b291$: regcomp failed:
| error: package gpg-pubkey-2039b291-3dbaae72 is not installed
| $ /tmp/rpm/bin/rpm -qa
| Freeing locks for locker 0xe: 22298/0
| Freeing locks for locker 0xf: 22298/0
| Freeing locks for locker 0x10:
On Sun, Jul 29, 2007, Ralf S. Engelschall wrote:
[...]
| $ /tmp/rpm/bin/rpm -e gpg-pubkey-2039b291-3dbaae72
| error: ^2039b291$: regcomp failed:
| error: package gpg-pubkey-2039b291-3dbaae72 is not installed
[...]
Please notice that until the erase operation everything was just fine.
Then
On Sun, Jul 29, 2007, Jeff Johnson wrote:
Jeff, can you investigate on this remaining issue, please?
Already investigated.
Guaranteeing that a rpmdb is closed gracefully under all possible
conditions is a fool's implementation.
Consider segfaults, kill -9, reboot, more.
So stale locks
On Jul 29, 2007, at 12:47 PM, Ralf S. Engelschall wrote:
On Sun, Jul 29, 2007, Jeff Johnson wrote:
Jeff, can you investigate on this remaining issue, please?
Already investigated.
Guaranteeing that a rpmdb is closed gracefully under all possible
conditions is a fool's implementation.
On Sun, Jul 29, 2007, Jeff Johnson wrote:
Yes, I agree, it is perfect that RPM is really able to detect and
cleanup in case of any aborts it has not under its own control (like
segfaults, kill -9, reboots, etc.) I really like that this is the case.
AFAICT, insque on a new development
A reminder: rpm man pages are in docbook under max-rpm ...
73 de Jeff
On Jul 29, 2007, at 2:47 PM, Ralf S. Engelschall wrote:
RPM Package Manager, CVS Repository
http://rpm5.org/cvs/
__
__
Server: rpm5.org
The dbenv is stateful, and per-instance. Why are you copying __db*
files around, they are useless, as you have seen, out of context.
73 de Jeff
On Jul 29, 2007, at 3:13 PM, Ralf S. Engelschall wrote:
Just a heads up for those of you who create the RPM DB in a temporary
location (like DESTDIR)
The option has been unnecessary in all but an obscure --root corner
case since Berkeley DB has been used.
Shall we finally eliminate the option?
73 de Jeff
__
RPM Package Manager
But then there is the other direction, lusers are surprised
that lazy mkdirs are done, with lazy rpmdb creattion as well:
rpm -qa --dbpath /tmp/XyZ
ls -al /tmp/XyZ
I've been going in booth legacy compatible strict and forward
looking loose
directions for years simultaneously.
Make
On Sun, Jul 29, 2007, Jeff Johnson wrote:
The dbenv is stateful, and per-instance. Why are you copying __db*
files around, they are useless, as you have seen, out of context.
Well, in OpenPKG since years we've created a database under
DESTDIRprefix/RPM/DB/ and this was later installed into the
On Sun, Jul 29, 2007, Jeff Johnson wrote:
The option has been unnecessary in all but an obscure --root corner
case since Berkeley DB has been used.
Shall we finally eliminate the option?
I personally would vote no.
In OpenPKG we even go the other direction: we use two small patch-hunks
(see
On Jul 29, 2007, at 5:00 PM, Jeff Johnson wrote:
Can we attempt run-time rather than compile time?
Truly, 3 ways in the API to open an rpmdb, none of which
take a path to the rpmdb, is rather odd.
I'd go radically the other way as well. Aside from path (and too
many options to ever manage
[EMAIL PROTECTED] wrote:
On Sun, Jul 29, 2007, Jeff Johnson wrote:
The dbenv is stateful, and per-instance. Why are you copying __db*
files around, they are useless, as you have seen, out of context.
Well, in OpenPKG since years we've created a database under
DESTDIRprefix/RPM/DB/ and
19 matches
Mail list logo
