|
List Info
Thread: Build of rpm-4.4.x (Linux x86_64)
|
|
| Build of rpm-4.4.x (Linux x86_64) |

|
2006-03-21 10:11:19 |
I'm new to this list, please forgive me if I'm covering
well-trodden
ground (I didn't see any duplication in the archive).
I've had a few
problems configuring and building recent releases of RPM
from their CVS
release tags. I have been working on tags rpm-4_4_2-release
to
rpm-4_4_5-release with varying degrees of success. I was
hoping for
some comment or suggestions from the sages on this list
about what went
wrong for me:
* Firstly if I pass any configure options to autogen.sh, it
complains:
# ./autogen.sh --option1 --option2 --option3
[...]
./autogen.sh: line 34: [: too many arguments
This is a valid thing to expect to do though, right?
Here's a small
patch, which I hope is still portable:
--- rpm-orig/autogen.sh 2005-11-29 22:18:56.000000000 +0000
+++ rpm/autogen.sh 2006-03-15 09:38:40.000000000 +0000
 -31,7
+31,7 
[ "`automake --version | head -1 | sed -e
's/1\.4[a-z]/1.4/'`" !=
"$AMV" ] && echo "$USAGE" #
&& exit 1
myopts=
-if [ X"$ " = X -a "X`uname -s`"
= "XDarwin" -a -d /opt/local ]; then
+if [ X"$*" = X -a "X`uname -s`" =
"XDarwin" -a -d /opt/local ]; then
export myopts="--prefix=/usr
--disable-nls"
export CPPFLAGS="-I$/include"
fi
 -69,7
+69,7 
exit 0;
fi
-if [ X"$ " = X -a "X`uname -s`"
= "XLinux" ]; then
+if [ X"$*" = X -a "X`uname -s`" =
"XLinux" ]; then
if [ -d /usr/share/man ]; then
mandir=/usr/share/man
infodir=/usr/share/info
* configure complains about the lack of directory 'wnh'.
I dropped
this from the autoconf directory list with no apparent
side-effects.
Is wnh something I actually need, or is it on its way in or
way out?
* I noticed that the --with-perl and --with-apidocs
arguments to
configure don't work. Looks like the autoconf script needs
these
fixes:
--- rpm-orig/configure.ac 2005-11-29
22:18:56.000000000 +0000
+++ rpm/configure.ac 2006-03-15 09:50:17.000000000 +0000
 -957,6
+957,7 
dnl
AC_ARG_WITH(perl, [ --with-perl build rpm
perl bindings
])
+WITH_PERL_VERSION=$withval
if test "$WITH_PERL_VERSION" != no ; then
WITH_PERL_SUBDIR=perl
WITH_PERL_SUBPACKAGE=1
 -1048,6
+1049,15 
elif test $withval = yes -a $__DOXYGEN = no ; then
AC_MSG_ERROR(--> rpm API docs needs doxygen in PATH)
fi
+if test $withval = yes; then
+ WITH_APIDOCS_TARGET=apidocs
+ WITH_APIDOCS=1
+else
+ WITH_APIDOCS=0
+fi
+AC_SUBST(WITH_APIDOCS_TARGET)
+AC_SUBST(WITH_APIDOCS)
+
WITH_SELINUX_LIB=
withval=$
 -1073,15
+1083,6 
AC_SUBST(WITH_LUA_SUBDIR)
AC_SUBST(WITH_LUA_INCLUDE)
-if test $withval = yes; then
- WITH_APIDOCS_TARGET=apidocs
- WITH_APIDOCS=1
-else
- WITH_APIDOCS=0
-fi
-AC_SUBST(WITH_APIDOCS_TARGET)
-AC_SUBST(WITH_APIDOCS)
-
withval=no
AC_ARG_WITH(dmalloc, [ --with-dmalloc build with
dmalloc
debugging support ])
if test $withval = yes ; then
* I also had problems building the embedded zlib and file
modules after
a recursive configure. RPM's configure script was giving
them a
top_builddir value of '.', which meant they were looking
for zlib
libraries in the wrong place. I didn't have an easy
suggestion for
fixing this, in the end I would configure those directories
separately
after configuring rpm and before starting the make. Any
ideas what is
going wrong here?
* I found that the --with-lua option could not be used to
disable Lua -
it's presence is assumed by psm.c in librpm so the build
fails. Should
it be possible to build RPM without Lua?
* I found that the embedded zlib's rpmz_ prefix caused
problems,
because libxml (which apparently is also in the mix) assumes
a zlib
without namespace prefix. Actually I didn't see any usage
of a zlib
with rpmz_ namespace prefix in the RPM sources so out that
went. Is
this something that is being phased in?
* In order to make a static build I had to add a bunch of
library
references to the LDADD macros in the top-level and tools/
auto-makefiles. Being fairly ignorant of autoconf/automake
magic I've
probably done it wrongly but can supply what I did if
you're
interested.
* In RPM 4.4.4 and 4.4.5 I get an error about
LUA_SPLINT_SOURCES. It
appears the _SOURCES suffix is upsetting automake, so I
renamed it to
_SRCS and things went much better.
With these changes applied I got a successful build. As an
encore it
even cross-compiled. Any advice or comments about what I
did above
would be gratefully received.
Regards,
Stig Telfer
_______________________________________________
Rpm-devel mailing list
Rpm-devel lists.dulug.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel
a>
|
|
| Build of rpm-4.4.x (Linux x86_64) |

|
2006-03-23 02:04:47 |
Most of these changes look dead-on to me. Thanks for the
patch!
I should have the changes in rpm-4.4.6 this week.
73 de Jeff
On Mar 21, 2006, at 5:11 AM, Stig Telfer wrote:
> I'm new to this list, please forgive me if I'm
covering well-
> trodden ground (I didn't see any duplication in the
archive). I've
> had a few problems configuring and building recent
releases of RPM
> from their CVS release tags. I have been working on
tags rpm-4_4_2-
> release to rpm-4_4_5-release with varying degrees of
success. I
> was hoping for some comment or suggestions from the
sages on this
> list about what went wrong for me:
>
> * Firstly if I pass any configure options to
autogen.sh, it complains:
>
> # ./autogen.sh --option1 --option2 --option3
> [...]
> ./autogen.sh: line 34: [: too many arguments
>
> This is a valid thing to expect to do though, right?
Here's a
> small patch, which I hope is still portable:
>
> --- rpm-orig/autogen.sh 2005-11-29 22:18:56.000000000
+0000
> +++ rpm/autogen.sh 2006-03-15 09:38:40.000000000
+0000
>  -31,7 +31,7 
> [ "`automake --version | head -1 | sed -e
's/1\.4[a-z]/1.4/'`" !=
> "$AMV" ] && echo
"$USAGE" # && exit 1
>
> myopts=
> -if [ X"$ " = X -a "X`uname -s`"
= "XDarwin" -a -d /opt/local ]; then
> +if [ X"$*" = X -a "X`uname
-s`" = "XDarwin" -a -d /opt/local ]; then
> export myopts="--prefix=/usr
--disable-nls"
> export
CPPFLAGS="-I$/include"
> fi
>  -69,7 +69,7 
> exit 0;
> fi
>
> -if [ X"$ " = X -a "X`uname -s`"
= "XLinux" ]; then
> +if [ X"$*" = X -a "X`uname
-s`" = "XLinux" ]; then
> if [ -d /usr/share/man ]; then
> mandir=/usr/share/man
> infodir=/usr/share/info
>
>
> * configure complains about the lack of directory
'wnh'. I dropped
> this from the autoconf directory list with no apparent
side-
> effects. Is wnh something I actually need, or is it on
its way in
> or way out?
>
>
> * I noticed that the --with-perl and --with-apidocs
arguments to
> configure don't work. Looks like the autoconf script
needs these
> fixes:
>
> --- rpm-orig/configure.ac 2005-11-29
22:18:56.000000000 +0000
> +++ rpm/configure.ac 2006-03-15 09:50:17.000000000
+0000
>  -957,6 +957,7 
> dnl
> AC_ARG_WITH(perl, [ --with-perl build
rpm perl
> bindings ])
>
> +WITH_PERL_VERSION=$withval
> if test "$WITH_PERL_VERSION" != no ; then
> WITH_PERL_SUBDIR=perl
> WITH_PERL_SUBPACKAGE=1
>  -1048,6 +1049,15 
> elif test $withval = yes -a $__DOXYGEN = no ; then
> AC_MSG_ERROR(--> rpm API docs needs doxygen in
PATH)
> fi
> +if test $withval = yes; then
> + WITH_APIDOCS_TARGET=apidocs
> + WITH_APIDOCS=1
> +else
> + WITH_APIDOCS=0
> +fi
> +AC_SUBST(WITH_APIDOCS_TARGET)
> +AC_SUBST(WITH_APIDOCS)
> +
>
> WITH_SELINUX_LIB=
> withval=$
>  -1073,15 +1083,6 
> AC_SUBST(WITH_LUA_SUBDIR)
> AC_SUBST(WITH_LUA_INCLUDE)
>
> -if test $withval = yes; then
> - WITH_APIDOCS_TARGET=apidocs
> - WITH_APIDOCS=1
> -else
> - WITH_APIDOCS=0
> -fi
> -AC_SUBST(WITH_APIDOCS_TARGET)
> -AC_SUBST(WITH_APIDOCS)
> -
> withval=no
> AC_ARG_WITH(dmalloc, [ --with-dmalloc build
with dmalloc
> debugging support ])
> if test $withval = yes ; then
>
>
> * I also had problems building the embedded zlib and
file modules
> after a recursive configure. RPM's configure script
was giving
> them a top_builddir value of '.', which meant they
were looking for
> zlib libraries in the wrong place. I didn't have an
easy
> suggestion for fixing this, in the end I would
configure those
> directories separately after configuring rpm and before
starting
> the make. Any ideas what is going wrong here?
>
>
> * I found that the --with-lua option could not be used
to disable
> Lua - it's presence is assumed by psm.c in librpm so
the build
> fails. Should it be possible to build RPM without Lua?
>
>
> * I found that the embedded zlib's rpmz_ prefix caused
problems,
> because libxml (which apparently is also in the mix)
assumes a zlib
> without namespace prefix. Actually I didn't see any
usage of a
> zlib with rpmz_ namespace prefix in the RPM sources so
out that
> went. Is this something that is being phased in?
>
>
> * In order to make a static build I had to add a bunch
of library
> references to the LDADD macros in the top-level and
tools/ auto-
> makefiles. Being fairly ignorant of autoconf/automake
magic I've
> probably done it wrongly but can supply what I did if
you're
> interested.
>
>
> * In RPM 4.4.4 and 4.4.5 I get an error about
LUA_SPLINT_SOURCES.
> It appears the _SOURCES suffix is upsetting automake,
so I renamed
> it to _SRCS and things went much better.
>
>
> With these changes applied I got a successful build.
As an encore
> it even cross-compiled. Any advice or comments about
what I did
> above would be gratefully received.
>
> Regards,
> Stig Telfer
>
> _______________________________________________
> Rpm-devel mailing list
> Rpm-devel lists.dulug.duke.edu
> https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel
a>
_______________________________________________
Rpm-devel mailing list
Rpm-devel lists.dulug.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel
a>
|
|
| Build of rpm-4.4.x (Linux x86_64) |

|
2006-03-23 13:29:43 |
On Wed, Mar 22, 2006 at 09:04:47PM -0500, Jeff Johnson
wrote:
> >* I found that the --with-lua option could not be
used to disable
> >Lua - it's presence is assumed by psm.c in librpm
so the build
> >fails. Should it be possible to build RPM without
Lua?
I used the following patch fur SuSE (but lua is actually
enabled):
--- ./Makefile.am.orig 2005-12-14 19:14:50.000000000 +0000
+++ ./Makefile.am 2005-12-16 14:22:04.000000000 +0000
 -15,7
+15,7  EXTRA_DIST = CHANGES CREDITS Doxyheader
po/*.in po/*.po po/rpm.pot \
rpm.magic rpmpopt-$(VERSION) rpmqv.c rpm.c
-SUBDIRS = intl po misc WITH_ZLIB_SUBDIR WITH_ELFUTILS_SUBDIR WITH_MAGIC_SUBDIR WITH_DB_SUBDIR WITH_SQLITE3_SUBDIR WITH_POPT_SUBDIR WITH_BEECRYPT_SUBDIR WITH_NEON_SUBDIR lua
rpmio rpmdb lib build WITH_PYTHON_SUBDIR tools scripts tests doc .
+SUBDIRS = intl po misc WITH_ZLIB_SUBDIR WITH_ELFUTILS_SUBDIR WITH_MAGIC_SUBDIR WITH_DB_SUBDIR WITH_SQLITE3_SUBDIR WITH_POPT_SUBDIR WITH_BEECRYPT_SUBDIR WITH_NEON_SUBDIR WITH_LUA_SUBDIR rpmio rpmdb lib build WITH_PYTHON_SUBDIR tools scripts tests doc .
INCLUDES = \
-I$(top_srcdir)/build \
--- ./build/parseScript.c.orig 2005-12-16 18:34:36.000000000
+0000
+++ ./build/parseScript.c 2005-12-16 18:36:08.000000000
+0000
 -283,6
+283,7  int parseScript(Spec spec, int parsePart
stripTrailingBlanksStringBuf(sb);
p = getStringBuf(sb);
+#ifdef WITH_LUA
if (!strcmp(progArgv[0], "<lua>")) {
rpmlua lua = NULL; /* Global state. */
if (rpmluaCheckScript(lua, p, partname) != RPMRC_OK) {
 -291,7
+292,9  int parseScript(Spec spec, int parsePart
}
(void) rpmlibNeedsFeature(pkg->header,
"BuiltinLuaScripts",
"4.2.2-1");
- } else if (progArgv[0][0] == '<') {
+ } else
+#endif
+ if (progArgv[0][0] == '<') {
rpmError(RPMERR_BADSPEC,
_("line %d: unsupported internal script:
%s\n"),
spec->lineNum, progArgv[0]);
--- ./lib/psm.c.orig 2005-12-14 18:59:10.000000000 +0000
+++ ./lib/psm.c 2006-02-24 11:46:54.000000000 +0000
 -490,6
+490,7  static pid_t psmWait(rpmpsm psm)
return psm->sq.reaped;
}
+#ifdef WITH_LUA
/**
* Run internal Lua script.
*/
 -572,6
+573,7  static rpmRC runLuaScript(rpmpsm psm, He
return rc;
}
+#endif
/**
*/
 -637,11
+639,15  static rpmRC runScript(rpmpsm psm, Heade
xx = hge(h, RPMTAG_ARCH, NULL, (void **) &a, NULL);
if (progArgv && strcmp(progArgv[0],
"<lua>") == 0) {
+#ifdef WITH_LUA
rpmMessage(RPMMESS_DEBUG,
_("%s: %s(%s-%s-%s.%s) running <lua>
scriptlet.\n"),
psm->stepName, tag2sln(psm->scriptTag), n, v, r,
a);
return runLuaScript(psm, h, sln, progArgc, progArgv,
script, arg1, arg2);
+#else
+ return RPMRC_FAIL;
+#endif
}
psm->sq.reaper = 1;
--- ./lib/rpmlibprov.c.orig 2004-03-16 21:58:29.000000000
+0000
+++ ./lib/rpmlibprov.c 2005-12-16 20:07:58.000000000 +0000
 -51,9
+51,11  static struct rpmlibProvides_s rpmlibPro
{ "rpmlib(ConcurrentAccess)",
"4.1-1",
( RPMSENSE_EQUAL),
N_("package scriptlets may access the rpm
database while installing.") },
+#ifdef WITH_LUA
{ "rpmlib(BuiltinLuaScripts)",
"4.2.2-1",
( RPMSENSE_EQUAL),
N_("internal support for lua scripts.") },
+#endif
{ NULL, NULL, 0, NULL }
};
--- ./lib/rpmrc.c.orig 2005-01-17 18:46:23.000000000 +0000
+++ ./lib/rpmrc.c 2005-12-16 18:30:29.000000000 +0000
 -1883,7
+1873,9  int rpmReadConfigFiles(const char * file
}
/* Force Lua state initialization */
+#ifdef WITH_LUA
(void)rpmluaGetPrintBuffer(NULL);
+#endif
return 0;
}
Cheers,
Michael.
--
Michael Schroeder mls suse.de
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13
);}
_______________________________________________
Rpm-devel mailing list
Rpm-devel lists.dulug.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel
a>
|
|
| Build of rpm-4.4.x (Linux x86_64) |

|
2006-03-23 13:40:43 |
On Mar 23, 2006, at 8:29 AM, Michael Schroeder wrote:
> On Wed, Mar 22, 2006 at 09:04:47PM -0500, Jeff Johnson
wrote:
>>> * I found that the --with-lua option could not
be used to disable
>>> Lua - it's presence is assumed by psm.c in
librpm so the build
>>> fails. Should it be possible to build RPM
without Lua?
>
> I used the following patch fur SuSE (but lua is
actually enabled):
>
The patch is sane and I'm glad to hear that SuSE has lua
enabled.
But if everyone insists in customizing rpm by ripping out
stuff like
lua, then I will be forced
to add mandatory (rather than advisory) tracking
dependencies like
Requires: rpmlib(BuiltinLuaScripts)
to packages to ensure that a package that uses/needs lua is
associated with
a version of rpmlib that actually has lua.
And then I will have to change rpm itself to make
sufficiently
extensive use of lua
that those who wish to rip lua out of rpm give up and bail
to a
legacy version of rpm.
I'd *really* like not to force the issue if at all possible
Unused embedded lua hurts little,
and is nowhere near as much bloat as, say, having
openssl/beecrypt,
libxml2/expat, and 2 (or more)
versions of zlib linked into rpm.
Already, selinux enabled/disabled detection depends on
embedded lua,
that
should be a compelling reason to leave lua within rpm, at
least for
those who
want to run selinux.
73 de Jeff
>
> --- ./Makefile.am.orig 2005-12-14 19:14:50.000000000
+0000
> +++ ./Makefile.am 2005-12-16 14:22:04.000000000 +0000
>  -15,7 +15,7  EXTRA_DIST = CHANGES CREDITS Doxyheader
> po/*.in po/*.po po/rpm.pot \
> rpm.magic rpmpopt-$(VERSION) rpmqv.c rpm.c
>
> -SUBDIRS = intl po misc WITH_ZLIB_SUBDIR WITH_ELFUTILS_SUBDIR
> WITH_MAGIC_SUBDIR WITH_DB_SUBDIR WITH_SQLITE3_SUBDIR
> WITH_POPT_SUBDIR WITH_BEECRYPT_SUBDIR WITH_NEON_SUBDIR lua
> rpmio rpmdb lib build WITH_PYTHON_SUBDIR tools
scripts tests doc .
> +SUBDIRS = intl po misc WITH_ZLIB_SUBDIR WITH_ELFUTILS_SUBDIR
> WITH_MAGIC_SUBDIR WITH_DB_SUBDIR WITH_SQLITE3_SUBDIR
> WITH_POPT_SUBDIR WITH_BEECRYPT_SUBDIR WITH_NEON_SUBDIR
> WITH_LUA_SUBDIR rpmio rpmdb lib build WITH_PYTHON_SUBDIR tools
> scripts tests doc .
>
> INCLUDES = \
> -I$(top_srcdir)/build \
> --- ./build/parseScript.c.orig 2005-12-16
18:34:36.000000000 +0000
> +++ ./build/parseScript.c 2005-12-16 18:36:08.000000000
+0000
>  -283,6 +283,7  int parseScript(Spec spec, int parsePart
> stripTrailingBlanksStringBuf(sb);
> p = getStringBuf(sb);
>
> +#ifdef WITH_LUA
> if (!strcmp(progArgv[0],
"<lua>")) {
> rpmlua lua = NULL; /* Global state. */
> if (rpmluaCheckScript(lua, p, partname) != RPMRC_OK)
{
>  -291,7 +292,9  int parseScript(Spec spec, int parsePart
> }
> (void) rpmlibNeedsFeature(pkg->header,
> "BuiltinLuaScripts",
"4.2.2-1");
> - } else if (progArgv[0][0] == '<') {
> + } else
> +#endif
> + if (progArgv[0][0] == '<') {
> rpmError(RPMERR_BADSPEC,
> _("line %d: unsupported internal script:
%s\n"),
> spec->lineNum, progArgv[0]);
> --- ./lib/psm.c.orig 2005-12-14 18:59:10.000000000
+0000
> +++ ./lib/psm.c 2006-02-24 11:46:54.000000000 +0000
>  -490,6 +490,7  static pid_t psmWait(rpmpsm psm)
> return psm->sq.reaped;
> }
>
> +#ifdef WITH_LUA
> /**
> * Run internal Lua script.
> */
>  -572,6 +573,7  static rpmRC runLuaScript(rpmpsm psm, He
>
> return rc;
> }
> +#endif
>
> /**
> */
>  -637,11 +639,15  static rpmRC
runScript(rpmpsm psm, Heade
> xx = hge(h, RPMTAG_ARCH, NULL, (void **) &a,
NULL);
>
> if (progArgv && strcmp(progArgv[0],
"<lua>") == 0) {
> +#ifdef WITH_LUA
> rpmMessage(RPMMESS_DEBUG,
> _("%s: %s(%s-%s-%s.%s) running <lua>
scriptlet.\n"),
> psm->stepName, tag2sln(psm->scriptTag), n, v,
r, a);
> return runLuaScript(psm, h, sln, progArgc, progArgv,
> script, arg1, arg2);
> +#else
> + return RPMRC_FAIL;
> +#endif
> }
>
> psm->sq.reaper = 1;
> --- ./lib/rpmlibprov.c.orig 2004-03-16
21:58:29.000000000 +0000
> +++ ./lib/rpmlibprov.c 2005-12-16 20:07:58.000000000
+0000
>  -51,9 +51,11  static struct rpmlibProvides_s rpmlibPro
> { "rpmlib(ConcurrentAccess)",
"4.1-1",
> ( RPMSENSE_EQUAL),
> N_("package scriptlets may access the rpm
database while
> installing.") },
> +#ifdef WITH_LUA
> { "rpmlib(BuiltinLuaScripts)",
"4.2.2-1",
> ( RPMSENSE_EQUAL),
> N_("internal support for lua
scripts.") },
> +#endif
> { NULL, NULL, 0, NULL }
> };
>
> --- ./lib/rpmrc.c.orig 2005-01-17 18:46:23.000000000
+0000
> +++ ./lib/rpmrc.c 2005-12-16 18:30:29.000000000 +0000
>  -1883,7 +1873,9  int
rpmReadConfigFiles(const char * file
> }
>
> /* Force Lua state initialization */
> +#ifdef WITH_LUA
> (void)rpmluaGetPrintBuffer(NULL);
> +#endif
>
> return 0;
> }
>
> Cheers,
> Michael.
>
> --
> Michael Schroeder
mls suse.de
>
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13
);}
> _______________________________________________
> Rpm-devel mailing list
> Rpm-devel lists.dulug.duke.edu
> https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel
a>
_______________________________________________
Rpm-devel mailing list
Rpm-devel lists.dulug.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel
a>
|
|
| Build of rpm-4.4.x (Linux x86_64) |

|
2006-03-23 17:09:17 |
On 3/21/06, Stig Telfer <rpm-list lizardlogic.co.uk>
wrote:
> I'm new to this list, please forgive me if I'm
covering well-trodden
> ground (I didn't see any duplication in the archive).
I've had a few
> problems configuring and building recent releases of
RPM from their CVS
> release tags. I have been working on tags
rpm-4_4_2-release to
> rpm-4_4_5-release with varying degrees of success. I
was hoping for
> some comment or suggestions from the sages on this list
about what went
> wrong for me:
>
> * Firstly if I pass any configure options to
autogen.sh, it complains:
>
> # ./autogen.sh --option1 --option2 --option3
> [...]
> ./autogen.sh: line 34: [: too many arguments
>
> This is a valid thing to expect to do though, right?
Here's a small
> patch, which I hope is still portable:
>
> --- rpm-orig/autogen.sh 2005-11-29 22:18:56.000000000
+0000
> +++ rpm/autogen.sh 2006-03-15 09:38:40.000000000
+0000
>  -31,7 +31,7 
> [ "`automake --version | head -1 | sed -e
's/1\.4[a-z]/1.4/'`" !=
> "$AMV" ] && echo
"$USAGE" # && exit 1
>
> myopts=
> -if [ X"$ " = X -a "X`uname -s`"
= "XDarwin" -a -d /opt/local ]; then
> +if [ X"$*" = X -a "X`uname
-s`" = "XDarwin" -a -d /opt/local ]; then
> export myopts="--prefix=/usr
--disable-nls"
> export
CPPFLAGS="-I$/include"
> fi
>  -69,7 +69,7 
> exit 0;
> fi
>
> -if [ X"$ " = X -a "X`uname -s`"
= "XLinux" ]; then
> +if [ X"$*" = X -a "X`uname
-s`" = "XLinux" ]; then
> if [ -d /usr/share/man ]; then
> mandir=/usr/share/man
> infodir=/usr/share/info
>
Yes, "... --o1 -o2 --o3" is a valid thing to do.
OTOH, this is a valid thing to do as well
./autogen.sh '-o1 $xxx' -o2
which is essentially the difference between "$ "
and "$*" evaluation afaict.
>
> * configure complains about the lack of directory
'wnh'. I dropped
> this from the autoconf directory list with no apparent
side-effects.
> Is wnh something I actually need, or is it on its way
in or way out?
>
wnh is a sub-dir checkout from a different repository.
Either nuke in SUBDIRS
or do
mkdir wnh
touch wnh/Makefile.in
The wnh is not essential or even used by rpm, the directory
is there
because its convenient for me.
>
> * I noticed that the --with-perl and --with-apidocs
arguments to
> configure don't work. Looks like the autoconf script
needs these
> fixes:
>
> --- rpm-orig/configure.ac 2005-11-29
22:18:56.000000000 +0000
> +++ rpm/configure.ac 2006-03-15 09:50:17.000000000
+0000
>  -957,6 +957,7 
> dnl
> AC_ARG_WITH(perl, [ --with-perl build
rpm perl bindings
> ])
>
> +WITH_PERL_VERSION=$withval
> if test "$WITH_PERL_VERSION" != no ; then
> WITH_PERL_SUBDIR=perl
> WITH_PERL_SUBPACKAGE=1
>  -1048,6 +1049,15 
> elif test $withval = yes -a $__DOXYGEN = no ; then
> AC_MSG_ERROR(--> rpm API docs needs doxygen in
PATH)
> fi
> +if test $withval = yes; then
> + WITH_APIDOCS_TARGET=apidocs
> + WITH_APIDOCS=1
> +else
> + WITH_APIDOCS=0
> +fi
> +AC_SUBST(WITH_APIDOCS_TARGET)
> +AC_SUBST(WITH_APIDOCS)
> +
>
> WITH_SELINUX_LIB=
> withval=$
>  -1073,15 +1083,6 
> AC_SUBST(WITH_LUA_SUBDIR)
> AC_SUBST(WITH_LUA_INCLUDE)
>
> -if test $withval = yes; then
> - WITH_APIDOCS_TARGET=apidocs
> - WITH_APIDOCS=1
> -else
> - WITH_APIDOCS=0
> -fi
> -AC_SUBST(WITH_APIDOCS_TARGET)
> -AC_SUBST(WITH_APIDOCS)
> -
> withval=no
> AC_ARG_WITH(dmalloc, [ --with-dmalloc build
with dmalloc
> debugging support ])
> if test $withval = yes ; then
>
Yep, egregious cut-n-paste.
>
> * I also had problems building the embedded zlib and
file modules after
> a recursive configure. RPM's configure script was
giving them a
> top_builddir value of '.', which meant they were
looking for zlib
> libraries in the wrong place. I didn't have an easy
suggestion for
> fixing this, in the end I would configure those
directories separately
> after configuring rpm and before starting the make.
Any ideas what is
> going wrong here?
>
This is a harder issue, and one has to decide what one
wants.
The zlib internal to rpm has useful modiciations (for rpm)
to support
--rsyncable for rpm payloads.
Meanwhile, those modifications won't help or hurt other
executables
like rpmfile.
So the answer is It Really Doesn't Matter (much).
The custom autocrap for zlib is retrofitted on top of
standard zlib, and
is responsible for top_builddir="." I believe.
The issue doesn't matter
much until one tries to build rpm in a subdirectory iirc.
>
> * I found that the --with-lua option could not be used
to disable Lua -
> it's presence is assumed by psm.c in librpm so the
build fails. Should
> it be possible to build RPM without Lua?
>
With Michael schroder's patch, --with-lua will work.
>
> * I found that the embedded zlib's rpmz_ prefix caused
problems,
> because libxml (which apparently is also in the mix)
assumes a zlib
> without namespace prefix. Actually I didn't see any
usage of a zlib
> with rpmz_ namespace prefix in the RPM sources so out
that went. Is
> this something that is being phased in?
>
The "rpmz_" prefix from internal zlib/zconf.h
tries to prevent symbol
pollution when rpm's internal zlib is mixed with external
zlib, which
can/will happen when, say, rpm-python bindings are loaded.
Usually the symbol pollution doesn't matter (I know of only
a single
occurence from a rather large internal internal zlibn API
change).
And because the symbol pollution usually doesn't matter, I
only
get around to checking/updating zlib/zconf.h every couple
months or so.
>
> * In order to make a static build I had to add a bunch
of library
> references to the LDADD macros in the top-level and
tools/
> auto-makefiles. Being fairly ignorant of
autoconf/automake magic I've
> probably done it wrongly but can supply what I did if
you're
> interested.
>
Hmm, do you have *.la files? If those were present (and
correct), then
little more than
-lrpm
should have been needed. That is the intent anyways, Fedora
Core removing
*.la files notwithstanding.
But adding to LDADD should correct build failures from
missing *.la files.
>
> * In RPM 4.4.4 and 4.4.5 I get an error about
LUA_SPLINT_SOURCES. It
> appears the _SOURCES suffix is upsetting automake, so I
renamed it to
> _SRCS and things went much better.
>
Yep.
>
> With these changes applied I got a successful build.
As an encore it
> even cross-compiled. Any advice or comments about what
I did above
> would be gratefully received.
>
Cool, cross compiled too!
Thanks for the patch, should be in (with Michael Schroder's
WITH_LUA patch)
in rpm-4.4.6-0.8 when built.
73 de Jeff
> Regards,
> Stig Telfer
>
> _______________________________________________
> Rpm-devel mailing list
> Rpm-devel lists.dulug.duke.edu
> https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel
a>
>
_______________________________________________
Rpm-devel mailing list
Rpm-devel lists.dulug.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel
a>
|
|
| Build of rpm-4.4.x (Linux x86_64) |

|
2006-03-27 13:19:40 |
On 23 Mar 2006, at 13:40, Jeff Johnson wrote:
>
> On Mar 23, 2006, at 8:29 AM, Michael Schroeder wrote:
>
>> On Wed, Mar 22, 2006 at 09:04:47PM -0500, Jeff
Johnson wrote:
>>>> * I found that the --with-lua option could
not be used to disable
>>>> Lua - it's presence is assumed by psm.c in
librpm so the build
>>>> fails. Should it be possible to build RPM
without Lua?
>>
>> I used the following patch fur SuSE (but lua is
actually enabled):
>>
>
> The patch is sane and I'm glad to hear that SuSE has
lua enabled.
>
> But if everyone insists in customizing rpm by ripping
out stuff like
> lua, then I will be forced
> to add mandatory (rather than advisory) tracking
dependencies like
> Requires: rpmlib(BuiltinLuaScripts)
> to packages to ensure that a package that uses/needs
lua is associated
> with
> a version of rpmlib that actually has lua.
>
> And then I will have to change rpm itself to make
sufficiently
> extensive use of lua
> that those who wish to rip lua out of rpm give up and
bail to a legacy
> version of rpm.
>
> I'd *really* like not to force the issue if at all
possible Unused
> embedded lua hurts little,
> and is nowhere near as much bloat as, say, having
openssl/beecrypt,
> libxml2/expat, and 2 (or more)
> versions of zlib linked into rpm.
>
> Already, selinux enabled/disabled detection depends on
embedded lua,
> that
> should be a compelling reason to leave lua within rpm,
at least for
> those who
> want to run selinux.
I have contributed far too little to be confident offering
opinions on
rpm, and my work on an embedded application represents a
mere speck of
dust in the universe of rpm users. However, from my
perspective, it is
helpful if anything that is not central to rpm's operation
can be
removable. Obviously there are priorities: a small addition
(as Lua
claims to be) is less of a burden than a larger one.
I was interested by your inclusion of openssl as an
alternative to
beecrypt. We already have openssl on our system - can RPM
really use
that in place of beecrypt?
Stig
_______________________________________________
Rpm-devel mailing list
Rpm-devel lists.dulug.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel
a>
|
|
| Build of rpm-4.4.x (Linux x86_64) |

|
2006-03-27 13:38:51 |
On Mar 27, 2006, at 8:19 AM, Stig Telfer wrote:
>
>
> I have contributed far too little to be confident
offering opinions
> on rpm, and my work on an embedded application
represents a mere
> speck of dust in the universe of rpm users. However,
from my
> perspective, it is helpful if anything that is not
central to rpm's
> operation can be removable. Obviously there are
priorities: a
> small addition (as Lua claims to be) is less of a
burden than a
> larger one.
>
All depends on POV. From my rpm POV, embedded lua can be
used freely
w/o the stiff and awkward necessity
of adding beaucoup dependencies which will never solve the
fundamental problem, that rpm needs to be
fully functional in an entirely unpopulated and empty
chroot.
No embedded scripting == no solution to the above. Lua is as
good as
any other embedded interpreter I've seen.
> I was interested by your inclusion of openssl as an
alternative to
> beecrypt. We already have openssl on our system - can
RPM really
> use that in place of beecrypt?
>
It's all about the API's, and openssl crypto has a
particularly
grotty API, and a non-LGPL license as well.
What exactly is gained by using openssl rather than beecrypt
for
crypto algorithms? The real problem
is the bleeping binary formats used to represent the
signatures, both
X.509 and OpenPGP parsers
are insanely obscure and complicated.
Note that adding openssl with its incompatible ABI's adds a
hugely
complicated prerequisite to
installing rpm. Yes, the prerequsite currently exists
because of
linking libneon, but I'd much
rather see an openssl-like API wrapping of beecrypt under
libneon, or
perhaps making https
support run-time optional through dlopen, than to try to
rewrite all
the existing crypto in rpm to use openssl
(and gcrypt and ...) instead.
FWIW, beecrypt has a quite pleasant, useful, and well
documented API,
and the code is beautifully written.
I also think that beecrypt probably performs at least as
well as any
other known crypto implementation, the
use of a mpw typedef to hide the ookiness of 32/64 bit
access is
extremely elegant, and the native endian
(i.e. bytes within ints are native endian, words are always
big-
wordian if you will) is fundamentally a
sounder multi-precision integer representation than anything
else
I've looked at.
So why should openssl be used instead?
73 de Jeff
_______________________________________________
Rpm-devel mailing list
Rpm-devel lists.dulug.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel
a>
|
|
| Build of rpm-4.4.x (Linux x86_64) |

|
2006-03-27 18:43:03 |
On 27 Mar 2006, at 14:38, Jeff Johnson wrote:
[...]
>> I was interested by your inclusion of openssl as an
alternative to
>> beecrypt. We already have openssl on our system -
can RPM really use
>> that in place of beecrypt?
>>
>
> It's all about the API's, and openssl crypto has a
particularly grotty
> API, and a non-LGPL license as well.
>
> What exactly is gained by using openssl rather than
beecrypt for
> crypto algorithms? The real problem
> is the bleeping binary formats used to represent the
signatures, both
> X.509 and OpenPGP parsers
> are insanely obscure and complicated.
>
> Note that adding openssl with its incompatible ABI's
adds a hugely
> complicated prerequisite to
> installing rpm. Yes, the prerequsite currently exists
because of
> linking libneon, but I'd much
> rather see an openssl-like API wrapping of beecrypt
under libneon, or
> perhaps making https
> support run-time optional through dlopen, than to try
to rewrite all
> the existing crypto in rpm to use openssl
> (and gcrypt and ...) instead.
>
> FWIW, beecrypt has a quite pleasant, useful, and well
documented API,
> and the code is beautifully written.
>
> I also think that beecrypt probably performs at least
as well as any
> other known crypto implementation, the
> use of a mpw typedef to hide the ookiness of 32/64 bit
access is
> extremely elegant, and the native endian
> (i.e. bytes within ints are native endian, words are
always
> big-wordian if you will) is fundamentally a
> sounder multi-precision integer representation than
anything else I've
> looked at.
>
> So why should openssl be used instead?
Apologies, I think I misunderstood your initial mail and
thought you
meant either openssl or beecrypt could be linked with rpm.
As it turns
out it seems both are part of a standard build.
I don't know much about the internals, but I agree that
openssl seems
large and unwieldy. Perhaps it does a lot for its size but
I have
difficulty in reducing it to the functionality I'm looking
for (working
on an embedded system means I have a fixed application to
support and
an eye on the resource budget).
On the question of why openssl should be used instead - it
is not a
question of openssl advocacy. It is only that our system
already
depends on it for openssh. I suppose the question could be
answered
with another question - is there an ssh implementation based
on
beecrypt? I'd be quite happy with that...
Regards,
Stig
_______________________________________________
Rpm-devel mailing list
Rpm-devel lists.dulug.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel
a>
|
|
| Build of rpm-4.4.x (Linux x86_64) |

|
2006-03-27 18:51:39 |
On Mar 27, 2006, at 1:43 PM, Stig Telfer wrote:
>
> On 27 Mar 2006, at 14:38, Jeff Johnson wrote:
> [...]
>>> I was interested by your inclusion of openssl
as an alternative
>>> to beecrypt. We already have openssl on our
system - can RPM
>>> really use that in place of beecrypt?
>>>
>>
>> It's all about the API's, and openssl crypto has
a particularly
>> grotty API, and a non-LGPL license as well.
>>
>> What exactly is gained by using openssl rather than
beecrypt for
>> crypto algorithms? The real problem
>> is the bleeping binary formats used to represent
the signatures,
>> both X.509 and OpenPGP parsers
>> are insanely obscure and complicated.
>>
>> Note that adding openssl with its incompatible
ABI's adds a hugely
>> complicated prerequisite to
>> installing rpm. Yes, the prerequsite currently
exists because of
>> linking libneon, but I'd much
>> rather see an openssl-like API wrapping of beecrypt
under libneon,
>> or perhaps making https
>> support run-time optional through dlopen, than to
try to rewrite
>> all the existing crypto in rpm to use openssl
>> (and gcrypt and ...) instead.
>>
>> FWIW, beecrypt has a quite pleasant, useful, and
well documented
>> API, and the code is beautifully written.
>>
>> I also think that beecrypt probably performs at
least as well as
>> any other known crypto implementation, the
>> use of a mpw typedef to hide the ookiness of 32/64
bit access is
>> extremely elegant, and the native endian
>> (i.e. bytes within ints are native endian, words
are always big-
>> wordian if you will) is fundamentally a
>> sounder multi-precision integer representation than
anything else
>> I've looked at.
>>
>> So why should openssl be used instead?
>
> Apologies, I think I misunderstood your initial mail
and thought
> you meant either openssl or beecrypt could be linked
with rpm. As
> it turns out it seems both are part of a standard
build.
>
Nah, I meant both openssl and beecrypt are used in rpm
currently,
that's bloated, and hence less than ideal.
I suspect we both agree on that.
> I don't know much about the internals, but I agree
that openssl
> seems large and unwieldy. Perhaps it does a lot for
its size but I
> have difficulty in reducing it to the functionality
I'm looking for
> (working on an embedded system means I have a fixed
application to
> support and an eye on the resource budget).
>
> On the question of why openssl should be used instead -
it is not a
> question of openssl advocacy. It is only that our
system already
> depends on it for openssh. I suppose the question
could be
> answered with another question - is there an ssh
implementation
> based on beecrypt? I'd be quite happy with that...
>
I wish there were more implementations that use beecrypt.
Alas, no ssh
+beecrypt exists. Well there's a chance that
there may be a java ssh that uses beecrypt, as beecrypt is
more
widely used in java land.
Anyways, ripping http support out of rpm will lose a great
deal of
baggage for your embedded application, and probably
is no more than 10 or so #ifdef's.
73 de Jeff
_______________________________________________
Rpm-devel mailing list
Rpm-devel lists.dulug.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel
a>
|
|
[1-9]
|
|