List Info

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




Build of rpm-4.4.x (Linux x86_64)
user name
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-devellists.dulug.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel
Build of rpm-4.4.x (Linux x86_64)
user name
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-devellists.dulug.duke.edu
> https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel

_______________________________________________
Rpm-devel mailing list
Rpm-devellists.dulug.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel
Build of rpm-4.4.x (Linux x86_64)
user name
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                                   mlssuse.de
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13
);}
_______________________________________________
Rpm-devel mailing list
Rpm-devellists.dulug.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel
Build of rpm-4.4.x (Linux x86_64)
user name
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                                  
mlssuse.de
>
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13
);}
> _______________________________________________
> Rpm-devel mailing list
> Rpm-devellists.dulug.duke.edu
> https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel

_______________________________________________
Rpm-devel mailing list
Rpm-devellists.dulug.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel
Build of rpm-4.4.x (Linux x86_64)
user name
2006-03-23 17:09:17
On 3/21/06, Stig Telfer <rpm-listlizardlogic.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-devellists.dulug.duke.edu
> https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel
>
_______________________________________________
Rpm-devel mailing list
Rpm-devellists.dulug.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel
Build of rpm-4.4.x (Linux x86_64)
user name
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-devellists.dulug.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel
Build of rpm-4.4.x (Linux x86_64)
user name
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-devellists.dulug.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel
Build of rpm-4.4.x (Linux x86_64)
user name
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-devellists.dulug.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel
Build of rpm-4.4.x (Linux x86_64)
user name
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-devellists.dulug.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel
[1-9]

about | contact  Other archives ( Real Estate discussion Medical topics )