Patch is fin, but ...
Likely should end up in system.h or even better, debug.h.
But I still don't know where to put _free() ...
On Jul 19, 2007, at 2:44 AM, Ralf S. Engelschall wrote:
RPM Package Manager, CVS Repository
http://rpm5.org/cvs/
Why not -g always? And is -O0 needed/recommended somewhere?
Just curious, I haven't had to fuss with -g -O2 on linux for years.
On Jul 19, 2007, at 2:39 AM, Ralf S. Engelschall wrote:
RPM Package Manager, CVS Repository
http://rpm5.org/cvs/
On Jul 18, 2007, at 4:17 PM, Thomas Lotterer wrote:
On Wednesday, 18. July 2007 at 9:49 pm, [EMAIL PROTECTED] wrote:
On Jul 18, 2007, at 3:35 PM, Thomas Lotterer wrote:
Did you look at the tcl bindings used for BDB "make check"?
I looked at them but the environment I was testing in did not
Nice catch.
On Jul 19, 2007, at 2:14 AM, Ralf S. Engelschall wrote:
RPM Package Manager, CVS Repository
http://rpm5.org/cvs/
__
__
Server: rpm5.org Name: Ralf S. Engelschall
Root:
In regard to: Re: Eliminating Berekeley DB/Sqlite3 in favor of a flat file...:
...snip...
but most projects go the opposite direction -- start
with lame-o filesystem database and move up to BDB later on.
Subversion is a good example of a large and popular software project
that went the other
On Wed, Jul 18, 2007, Michael Jennings wrote:
> [...clearly labeled versions in files...]
> causes problems with download scripts and spec files and such for no
> real gain.
Can you be more specific, please? What _particular_ "problems" in
download scripts and in .spec files are you talking about
On Wednesday, 18 July 2007, at 12:03:01 (+0200),
Ralf S. Engelschall wrote:
> Log:
> It is both confusing and problematic that the current RPM 5 on
> HEAD labels itself as just "5.0" and this way looks like the final
> release version. As for the snapshots we also need a clear labeli
On Jul 18, 2007, at 4:17 PM, Thomas Lotterer wrote:
On Wednesday, 18. July 2007 at 9:49 pm, [EMAIL PROTECTED] wrote:
On Jul 18, 2007, at 3:35 PM, Thomas Lotterer wrote:
Did you look at the tcl bindings used for BDB "make check"?
I looked at them but the environment I was testing in did not
On Wednesday, 18. July 2007 at 9:49 pm, [EMAIL PROTECTED] wrote:
> On Jul 18, 2007, at 3:35 PM, Thomas Lotterer wrote:
>
> Did you look at the tcl bindings used for BDB "make check"?
>
I looked at them but the environment I was testing in did not support
tcl. Also I have no experience in tcl. Bad
On Jul 18, 2007, at 3:35 PM, Thomas Lotterer wrote:
On Wednesday, 18. July 2007 at 7:54 pm, [EMAIL PROTECTED] wrote:
I never would have guessed that there are so many people that think
that having rpm use Berkeley DB is a bad thing.
Sad but true. I'm one of them. And it's more than thinking o
On Wednesday, 18. July 2007 at 7:54 pm, [EMAIL PROTECTED] wrote:
> I never would have guessed that there are so many people that think
> that having rpm use Berkeley DB is a bad thing.
>
Sad but true. I'm one of them. And it's more than thinking only and not
limited to rpm.
Over the years I fough
On Jul 18, 2007, at 2:49 PM, Thomas Lotterer wrote:
I've read the relevant parts of the document Jay was pointing out
and in fact
the "revlog" works in append mode only. Too specialized for our needs.
Append mode only is absolutely necessary to achieve "flat file"
performance.
Otherwis
On Jul 18, 2007, at 2:49 PM, Thomas Lotterer wrote:
On Wednesday, 18. July 2007 at 7:12 pm, [EMAIL PROTECTED] wrote:
On Jul 18, 2007, at 12:40 PM, Thomas Lotterer wrote:
FYI: Berkeley DB has the ability to have multiple tables within a
single
file.
Good to know.
One cannot just look at
On Jul 18, 2007, at 2:34 PM, Tim Mooney wrote:
I'm not at all against moving to a directory-as-key database, I'm just
surprised that a project that has such a long history with bdb has
that
on the table as an option. It's probably good to "rethink everything"
once in a while, but most pro
In regard to: Re: Eliminating Berekeley DB/Sqlite3 in favor of a flat file...:
;-) Glad to hear there are a few who do not dislike Berkeley DB.
I don't know that it's to the level of "Gold Standard", but Berkeley DB
is, in my experience, an extremely high quality piece of software. I'm
not a
On Wednesday, 18. July 2007 at 7:12 pm, [EMAIL PROTECTED] wrote:
> On Jul 18, 2007, at 12:40 PM, Thomas Lotterer wrote:
>>
> FYI: Berkeley DB has the ability to have multiple tables within a single
> file.
>
Good to know.
> One cannot just look at the size of the data, one also has to look at the
...snip...
but most projects go the opposite direction -- start
with lame-o filesystem database and move up to BDB later on.
Subversion is a good example of a large and popular software project
that went the other direction with good results. It can certainly be
done, the question that needs
In regard to: Re: Eliminating Berekeley DB/Sqlite3 in favor of a flat file...:
On Jul 18, 2007, at 1:44 PM, Jeff Johnson wrote:
A single flat file with an offset can be substituted that is at least as
well
performing, but the implementation is more subtle because one needs
to keep track of
On Jul 18, 2007, at 1:54 PM, Tim Mooney wrote:
In regard to: Re: Eliminating Berekeley DB/Sqlite3 in favor of a
flat file...:
Evening folks,
On Wed, 18 Jul 2007, Jeff Johnson wrote:
Using flat files avoids all the complexity of rpmdb iterator
methods,
maximizes access of installed inform
On Jul 18, 2007, at 1:44 PM, Jeff Johnson wrote:
A single flat file with an offset can be substituted that is at
least as well
performing, but the implementation is more subtle because one needs
to keep track of the offset value to debug the mess. Not true for
files
in a directory, ls -a
In regard to: Re: Eliminating Berekeley DB/Sqlite3 in favor of a flat file...:
Evening folks,
On Wed, 18 Jul 2007, Jeff Johnson wrote:
Using flat files avoids all the complexity of rpmdb iterator methods,
maximizes access of installed information because only files need to be
opened, and permi
On Jul 18, 2007, at 1:38 PM, Robert Scheck wrote:
+1 if there is no or even very less performance loss at.
Stability and reliability are important issues to consider as well.
73 de Jeff
__
RPM Package Manager
On Jul 18, 2007, at 1:38 PM, Robert Scheck wrote:
Evening folks,
On Wed, 18 Jul 2007, Jeff Johnson wrote:
Using flat files avoids all the complexity of rpmdb iterator methods,
maximizes access of installed information because only files need
to be
opened, and permits 3rd party software inst
Evening folks,
On Wed, 18 Jul 2007, Jeff Johnson wrote:
> Using flat files avoids all the complexity of rpmdb iterator methods,
> maximizes access of installed information because only files need to be
> opened, and permits 3rd party software installers to simply write their
> metadata file goop
On Jul 18, 2007, at 12:40 PM, Thomas Lotterer wrote:
On Wednesday, 18. July 2007 at 3:21 pm, [EMAIL PROTECTED] wrote:
[Turn the world upside down] What say ye?
Wow. Even makes me posting to the top.
Among other things, my personal preference of SQLite over
BerkeleyDB comes from
the (almos
On Jul 18, 2007, at 12:39 PM, Ralf S. Engelschall wrote:
On Wed, Jul 18, 2007, Jeff Johnson wrote:
[...]
Or are you planning that RPM can be really internally run
multi-threaded? Then the case is different, of course. Then you
_have_
to use POSIX pthreads, of course.
rpm is already mult
On Wednesday, 18. July 2007 at 3:21 pm, [EMAIL PROTECTED] wrote:
> [Turn the world upside down] What say ye?
>
Wow. Even makes me posting to the top.
Among other things, my personal preference of SQLite over BerkeleyDB comes from
the (almost) single file per DB approach vs. single file per table
On Wed, Jul 18, 2007, Jeff Johnson wrote:
> [...]
>> Or are you planning that RPM can be really internally run
>> multi-threaded? Then the case is different, of course. Then you _have_
>> to use POSIX pthreads, of course.
>
> rpm is already multi-threaded many years now:
> rpm -Uvh --psmthrea
On Jul 18, 2007, at 9:28 AM, Jeff Johnson wrote:
Indices as append-only human readable flat files are also doable.
See the OLS
2006 paper on Mercury internals (I'll dig out the reference).
https://ols2006.108.redhat.com/reprints/mackall-reprint.pdf ?
What say ye?
+1. Very cool.
j.
_
On Jul 18, 2007, at 11:11 AM, Ralf S. Engelschall wrote:
On Wed, Jul 18, 2007, Jeff Johnson wrote:
[...]
If I read correctly, the conservative/portable approach is -
lpthread in
executable so that external libraries linked with -lpthread function
correctly. That kinda forces "mandatory" -lp
On Jul 18, 2007, at 11:11 AM, Ralf S. Engelschall wrote:
On Wed, Jul 18, 2007, Jeff Johnson wrote:
[...]
If I read correctly, the conservative/portable approach is -
lpthread in
executable so that external libraries linked with -lpthread function
correctly. That kinda forces "mandatory" -lp
On Wed, Jul 18, 2007, Jeff Johnson wrote:
> [...]
> If I read correctly, the conservative/portable approach is -lpthread in
> executable so that external libraries linked with -lpthread function
> correctly. That kinda forces "mandatory" -lpthread for rpm when
> external libraries may (or may not)
On Jul 18, 2007, at 10:49 AM, Ralf S. Engelschall wrote:
[...]
I have been linking -lpthreads in rpm because beecrypt uses
threads to
gather entropy, and because of posix-shared-mutexes.
BeeCrypt when built with --disable-threads uses a /dev/random just
fine
AFAIK. And the POSIX mutexe
On Wed, Jul 18, 2007, Jeff Johnson wrote:
> On Jul 18, 2007, at 10:14 AM, Ralf S. Engelschall wrote:
>
>> On Wed, Jul 18, 2007, Jeff Johnson wrote:
>>
>>> Ripping the need for -lpthread is on my todo list. Easier to rip than
>>> discuss.
>>
>> Well, a simple --without-pthreads now does the trick j
On Jul 18, 2007, at 10:14 AM, Ralf S. Engelschall wrote:
On Wed, Jul 18, 2007, Jeff Johnson wrote:
Ripping the need for -lpthread is on my todo list. Easier to rip than
discuss.
Well, a simple --without-pthreads now does the trick just fine and
allows one to build RPM without any needs for
On Wed, Jul 18, 2007, Jeff Johnson wrote:
> Ripping the need for -lpthread is on my todo list. Easier to rip than
> discuss.
Well, a simple --without-pthreads now does the trick just fine and
allows one to build RPM without any needs for an existing POSIX pthreads
API. That's all I personally nee
On Jul 18, 2007, at 9:11 AM, Ralf S. Engelschall wrote:
Whether the out-of-band snapshots are encoded es 9 (always newer than
the other three) or 0 (always older than the other three at then 1/2/3
instead of 0/1/2) can be still decided upon. But I think you now got
the idea what I'm talking ab
Secondary lookup using primary key is easily achieved with
headers located in a subdirectory.
Using the header id (aka the sha1 digest of the header) instead of
the current volatile header instance number as a more persistent join
key, using the first few hex digits for the directory name, with t
On Wed, Jul 18, 2007, Jeff Johnson wrote:
> On Jul 18, 2007, at 8:46 AM, Ralf S. Engelschall wrote:
>
>> On Wed, Jul 18, 2007, Jeff Johnson wrote:
>>
>>> Don't forget these in rpmlib.h too:
>>> #define RPM_FORMAT_VERSION 5
>>> #define RPM_MAJOR_VERSION 0
>>> #define RPM_MINOR_VERSION 0
Ripping the need for -lpthread is on my todo list. Easier to rip than
discuss.
73 de Jeff
On Jul 18, 2007, at 8:53 AM, Ralf S. Engelschall wrote:
RPM Package Manager, CVS Repository
http://rpm5.org/cvs/
__
__
On Jul 18, 2007, at 8:48 AM, Thomas Lotterer wrote:
Looked at "rpm -v --showrc" and like it.
Blew "--version" out of my mind. Thanks for the hint.
The --showrc output spew needs to be polished.
In particular, there are so many bleeping macros around now that they
need
to be displayed p
On Jul 18, 2007, at 8:46 AM, Ralf S. Engelschall wrote:
On Wed, Jul 18, 2007, Jeff Johnson wrote:
Don't forget these in rpmlib.h too:
#define RPM_FORMAT_VERSION 5
#define RPM_MAJOR_VERSION 0
#define RPM_MINOR_VERSION 0
Personally, I see little point in "branding" every bleeping o
On Wednesday, 18. July 2007 at 2:28 pm, [EMAIL PROTECTED] wrote:
> On Jul 18, 2007, at 8:15 AM, Thomas Lotterer wrote:
>> I was thinking of support issues this time and had cURL in my mind
>
> So because curl uses --version, rpm should?
>
No. Because cURL does, it was in my mind. Only an idea.
>
On Wed, Jul 18, 2007, Jeff Johnson wrote:
> Don't forget these in rpmlib.h too:
> #define RPM_FORMAT_VERSION 5
> #define RPM_MAJOR_VERSION 0
> #define RPM_MINOR_VERSION 0
>
> Personally, I see little point in "branding" every bleeping object
> produced by with identical stamps in order
On Jul 18, 2007, at 8:15 AM, Thomas Lotterer wrote:
On Wednesday, 18. July 2007 at 1:40 pm, [EMAIL PROTECTED] wrote:
On Jul 18, 2007, at 6:19 AM, Thomas Lotterer wrote:
I'd also like to see a collection of the various autofoo test
results to reveal the ingredients of the "rpm" executable.
S
Don't forget these in rpmlib.h too:
#define RPM_FORMAT_VERSION 5
#define RPM_MAJOR_VERSION 0
#define RPM_MINOR_VERSION 0
Personally, I see little point in "branding" every bleeping object
produced by with identical stamps in order to signify "DEVEL".
My FTP logs from the last 2 years
On Wednesday, 18. July 2007 at 1:40 pm, [EMAIL PROTECTED] wrote:
> On Jul 18, 2007, at 6:19 AM, Thomas Lotterer wrote:
>> I'd also like to see a collection of the various autofoo test
>> results to reveal the ingredients of the "rpm" executable.
>
> So the "Modular Framework" group wants a single
On Jul 18, 2007, at 5:06 AM, Michael Schroeder wrote:
On Wed, Jul 18, 2007 at 12:37:41PM +0400, Dmitry V. Levin wrote:
On Wed, Jul 18, 2007 at 10:07:27AM +0200, Michael Schroeder wrote:
On Wed, Jul 18, 2007 at 02:04:11AM +0400, Dmitry V. Levin wrote:
No, please do not apply this change.
The
On Jul 18, 2007, at 7:40 AM, Jeff Johnson wrote:
Remember that not only the /usr/bin/rpm executable, but also
bindings and run-time libraries
will need to discover the same information as the "rpm --version"
script kiddies,
so an API will be needed, not just `rpm --version`.
FYI: there
On Jul 18, 2007, at 6:19 AM, Thomas Lotterer wrote:
On Wednesday, 18. July 2007 at 12:03 pm, [EMAIL PROTECTED] wrote:
As for the snapshots we also need a clear labeling, let's start
using "N.M.DEVEL" for the development state in CVS and
"M.M.SNAPSHOT.MMDD" for the daily snapsho
On Wednesday, 18. July 2007 at 12:03 pm, [EMAIL PROTECTED] wrote:
> As for the snapshots we also need a clear labeling, let's start
> using "N.M.DEVEL" for the development state in CVS and
> "M.M.SNAPSHOT.MMDD" for the daily snapshots from CVS.
>
Thanks. A valuable aid for supp
On Wed, Jul 18, 2007 at 12:37:41PM +0400, Dmitry V. Levin wrote:
> On Wed, Jul 18, 2007 at 10:07:27AM +0200, Michael Schroeder wrote:
> > On Wed, Jul 18, 2007 at 02:04:11AM +0400, Dmitry V. Levin wrote:
> > > No, please do not apply this change.
> > > The problem is real, so let linker warnings rem
On Wed, Jul 18, 2007 at 10:07:27AM +0200, Michael Schroeder wrote:
> On Wed, Jul 18, 2007 at 02:04:11AM +0400, Dmitry V. Levin wrote:
> > No, please do not apply this change.
> > The problem is real, so let linker warnings remind us about this issue.
> The problem is *not* real, close(mkstemp()) lo
On Wed, Jul 18, 2007, Thomas Lotterer wrote:
> On Tue, Jul 17, 2007 at 9:05 PM, [EMAIL PROTECTED] wrote:
> > On Tue, Jul 17, 2007, Jeff Johnson wrote:
> >> On Jul 17, 2007, at 2:09 PM, Ralf S. Engelschall wrote:
> > I also thought we just recently had this discussion: there is no
> > distribution
On Tue, Jul 17, 2007 at 8:09 PM, [EMAIL PROTECTED] wrote:
> On Tue, Jul 17, 2007, Jeff Johnson wrote:
>> Try .../SNAPSHOTS/MMDD/rpm-5.0.tar.gz paths, one does not have to
>> duplicate information endlessly in order to distribute snapshots.
>
> Sorry, but I've to very strongly disagree. This wo
On Tue, Jul 17, 2007 at 9:05 PM, [EMAIL PROTECTED] wrote:
> On Tue, Jul 17, 2007, Jeff Johnson wrote:
>> On Jul 17, 2007, at 2:09 PM, Ralf S. Engelschall wrote:
> I also thought we just recently had this discussion: there is no
> distribution-neutral packaging, not even for source packages, isn't
On Wed, Jul 18, 2007 at 02:04:11AM +0400, Dmitry V. Levin wrote:
> No, please do not apply this change.
> The problem is real, so let linker warnings remind us about this issue.
The problem is *not* real, close(mkstemp()) looks a bit strange, but
is sane.
Cheers,
Michael.
--
Michael Schroeder
On Tue, Jul 17, 2007 at 10:19:48PM +0200, Ralf S. Engelschall wrote:
> I'm currently investigating on the mktemp/mkstemp(3) front
> and stumbled over IMHO totally broken uses in e.g. build.c:
>
> | tmpSpecFile = (char *) rpmGetPath("%{_specdir}/",
> "rpm-spec.XX", NULL);
> | #if defin
58 matches
Mail list logo
