package/beecrypt: add host variant

Required by an upcoming host variant of the rpm package.

---
 package/beecrypt/beecrypt.mk | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

index cd0b4ac..0d7b360 100644
@@ -11,16 +11,21 @@ BEECRYPT_INSTALL_STAGING = YES
 BEECRYPT_LICENSE = LGPLv2.1+
 BEECRYPT_LICENSE_FILES = COPYING.LIB
 
-BEECRYPT_CONF_OPTS = \
+BEECRYPT_CONFIGURE_ARGS = \
 	--disable-expert-mode \
 	--without-java \
 	--without-python \
 	--disable-openmp
 
+BEECRYPT_CONF_OPTS = $(BEECRYPT_CONFIGURE_ARGS)
+HOST_BEECRYPT_CONF_OPTS = $(BEECRYPT_CONFIGURE_ARGS)
+
 ifeq ($(BR2_PACKAGE_BEECRYPT_CPP),y)
 BEECRYPT_DEPENDENCIES += icu
+HOST_BEECRYPT_DEPENDENCIES += host-icu
 else
 BEECRYPT_CONF_OPTS += --without-cplusplus
+HOST_BEECRYPT_CONF_OPTS += --without-cplusplus
 
 # automake/libtool uses the C++ compiler to link libbeecrypt because of
 # (the optional) cppglue.cxx. Force it to use the C compiler instead.

@@ -29,6 +34,8 @@ define BEECRYPT_LINK_WITH_CC
 endef
 
 BEECRYPT_POST_CONFIGURE_HOOKS += BEECRYPT_LINK_WITH_CC
+HOST_BEECRYPT_POST_CONFIGURE_HOOKS += BEECRYPT_LINK_WITH_CC
 endif
 
 $(eval $(autotools-package))
+$(eval $(host-autotools-package))

1.9.5.msysgit.1

Required by an upcoming host variant of the rpm package.

---
 package/neon/neon.mk | 20 +++++++++++++++++++-
 1 file changed, 19 insertions(+), 1 deletion(-)

index 0cff1a2..adfc836 100644
@@ -9,42 +9,60 @@ NEON_SITE = http://www.webdav.org/neon
 NEON_LICENSE = LGPLv2+ (library), GPLv2+ (manual and tests)
 NEON_LICENSE_FILES = src/COPYING.LIB test/COPYING README
 NEON_INSTALL_STAGING = YES
-NEON_CONF_OPTS = --without-gssapi --disable-rpath
 NEON_CONFIG_SCRIPTS = neon-config
+
+NEON_CONF_OPTS = --without-gssapi --disable-rpath
 NEON_DEPENDENCIES = host-pkgconf
+HOST_NEON_CONF_OPTS = --without-gssapi --disable-rpath
+HOST_NEON_DEPENDENCIES = host-pkgconf
 
 ifeq ($(BR2_PACKAGE_NEON_ZLIB),y)
 NEON_CONF_OPTS += --with-zlib=$(STAGING_DIR)
 NEON_DEPENDENCIES += zlib
+HOST_NEON_CONF_OPTS += --with-zlib=$(HOST_DIR)
+HOST_NEON_DEPENDENCIES += host-zlib
 else
 NEON_CONF_OPTS += --without-zlib
+HOST_NEON_CONF_OPTS += --without-zlib
 endif
 
 ifeq ($(BR2_PACKAGE_NEON_SSL),y)
 NEON_CONF_OPTS += --with-ssl
 NEON_DEPENDENCIES += openssl
+HOST_NEON_CONF_OPTS += --with-ssl
+HOST_NEON_DEPENDENCIES += host-openssl
 else
 NEON_CONF_OPTS += --without-ssl
+HOST_NEON_CONF_OPTS += --without-ssl
 endif
 
 ifeq ($(BR2_PACKAGE_NEON_EXPAT),y)
 NEON_CONF_OPTS += --with-expat=$(STAGING_DIR)/usr/lib/libexpat.la
 NEON_DEPENDENCIES += expat
+HOST_NEON_CONF_OPTS += --with-expat=$(HOST_DIR)/usr/lib/libexpat.la
+HOST_NEON_DEPENDENCIES += host-expat
 else
 NEON_CONF_OPTS += --with-expat=no
+HOST_NEON_CONF_OPTS += --with-expat=no
 endif
 
 ifeq ($(BR2_PACKAGE_NEON_LIBXML2),y)
 NEON_CONF_OPTS += --with-libxml2=yes
 NEON_CONF_ENV += ac_cv_prog_XML2_CONFIG=$(STAGING_DIR)/usr/bin/xml2-config
 NEON_DEPENDENCIES += libxml2
+HOST_NEON_CONF_OPTS += --with-libxml2=yes
+HOST_NEON_CONF_ENV += ac_cv_prog_XML2_CONFIG=$(HOST_DIR)/usr/bin/xml2-config
+HOST_NEON_DEPENDENCIES += host-libxml2
 else
 NEON_CONF_OPTS += --with-libxml2=no
+HOST_NEON_CONF_OPTS += --with-libxml2=no
 endif
 
 ifeq ($(BR2_PACKAGE_NEON_EXPAT)$(BR2_PACKAGE_NEON_LIBXML2),)
 # webdav needs xml support
 NEON_CONF_OPTS += --disable-webdav
+HOST_NEON_CONF_OPTS += --disable-webdav
 endif
 
 $(eval $(autotools-package))
+$(eval $(host-autotools-package))

1.9.5.msysgit.1

Dear James Knight,

Same comments as for beecrypt: all the BR2_PACKAGE_* options should not be used to adjust the capabilities of the host package.

Thanks,

Thomas

Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

The following adds support for a host variant of the rpm package. This support will allow a host system to setup/manipulate a target system's initial RPM database during the post-build phase.

---
 package/Config.in.host     |  1 +
 package/rpm/Config.in.host |  6 ++++++
 package/rpm/rpm.mk         | 25 +++++++++++++++++++++++--
 3 files changed, 30 insertions(+), 2 deletions(-)
 create mode 100644 package/rpm/Config.in.host

index 1e047aa..1820b20 100644
@@ -22,6 +22,7 @@ menu "Host utilities"
 	source "package/patchelf/Config.in.host"
 	source "package/pwgen/Config.in.host"
 	source "package/qemu/Config.in.host"
+	source "package/rpm/Config.in.host"
 	source "package/sam-ba/Config.in.host"
 	source "package/squashfs/Config.in.host"
 	source "package/sunxi-tools/Config.in.host"

new file mode 100644
index 0000000..101f62c
@@ -0,0 +1,6 @@
+config BR2_PACKAGE_HOST_RPM
+	bool "host rpm"
+	help
+	  The RPM package management system.
+
+	  http://rpm5.org

index 7f346b2..c84ed04 100644
@@ -8,6 +8,7 @@ RPM_VERSION_MAJOR = 5.2
 RPM_VERSION = $(RPM_VERSION_MAJOR).0
 RPM_SITE = http://rpm5.org/files/rpm/rpm-$(RPM_VERSION_MAJOR)
 RPM_DEPENDENCIES = host-pkgconf zlib beecrypt neon popt openssl
+HOST_RPM_DEPENDENCIES = host-pkgconf host-zlib host-beecrypt host-neon host-popt host-openssl
 RPM_LICENSE = LGPLv2.1
 RPM_LICENSE_FILES = COPYING.LIB
 

@@ -15,7 +16,11 @@ RPM_CONF_ENV = \
 	CFLAGS="$(TARGET_CFLAGS) -I$(STAGING_DIR)/usr/include/beecrypt -I$(STAGING_DIR)/usr/include/neon -DHAVE_MUTEX_THREAD_ONLY" \
 	ac_cv_va_copy=yes
 
-RPM_CONF_OPTS = \
+HOST_RPM_CONF_ENV = \
+	CFLAGS="$(TARGET_CFLAGS) -I$(HOST_DIR)/usr/include/beecrypt -I$(HOST_DIR)/usr/include/neon -DHAVE_MUTEX_THREAD_ONLY" \
+	ac_cv_va_copy=yes
+
+RPM_CONFIGURE_ARGS = \
 	--disable-build-versionscript \
 	--disable-rpath \
 	--without-selinux \

@@ -23,42 +28,58 @@ RPM_CONF_OPTS = \
 	--without-perl \
 	--with-openssl=external \
 	--with-zlib=external \
-	--with-libbeecrypt=$(STAGING_DIR) \
 	--with-popt=external
 
+RPM_CONF_OPTS = $(RPM_CONFIGURE_ARGS) --with-libbeecrypt=$(STAGING_DIR)
+HOST_RPM_CONF_OPTS = $(RPM_CONFIGURE_ARGS) --with-libbeecrypt=$(HOST_DIR)
+
 ifeq ($(BR2_NEEDS_GETTEXT_IF_LOCALE),y)
 RPM_DEPENDENCIES += gettext
+HOST_RPM_DEPENDENCIES += host-gettext
 endif
 
 ifeq ($(BR2_PACKAGE_PCRE),y)
 RPM_DEPENDENCIES += pcre
 RPM_CONF_OPTS += --with-pcre=external
+HOST_RPM_CONF_OPTS += --with-pcre=external
 else
 RPM_CONF_OPTS += --with-pcre=none
+HOST_RPM_CONF_OPTS += --with-pcre=none
 endif
 
 ifeq ($(BR2_PACKAGE_FILE),y)
 RPM_DEPENDENCIES += file
 RPM_CONF_OPTS += --with-file=external
+HOST_RPM_DEPENDENCIES += host-file
+HOST_RPM_CONF_OPTS += --with-file=external
 else
 RPM_CONF_OPTS += --with-file=none
+HOST_RPM_CONF_OPTS += --with-file=none
 endif
 
 # xz payload support needs a toolchain w/ C++
 ifeq ($(BR2_PACKAGE_XZ)$(BR2_INSTALL_LIBSTDCPP),yy)
 RPM_DEPENDENCIES += xz
 RPM_CONF_OPTS += --with-xz=external
+HOST_RPM_DEPENDENCIES += host-xz
+HOST_RPM_CONF_OPTS += --with-xz=external
 else
 RPM_CONF_OPTS += --with-xz=none
+HOST_RPM_CONF_OPTS += --with-xz=none
 endif
 
 ifeq ($(BR2_PACKAGE_BZIP2),y)
 RPM_CONF_OPTS += --with-bzip2
 RPM_DEPENDENCIES += bzip2
+HOST_RPM_CONF_OPTS += --with-bzip2
+HOST_RPM_DEPENDENCIES += bzip2
 endif
 
 RPM_MAKE = $(MAKE1)
+HOST_RPM_MAKE = $(MAKE1)
 
 RPM_INSTALL_TARGET_OPTS = DESTDIR=$(TARGET_DIR) program_transform_name= install
+HOST_RPM_INSTALL_TARGET_OPTS = DESTDIR=$(HOST_DIR) program_transform_name= install
 
 $(eval $(autotools-package))
+$(eval $(host-autotools-package))

1.9.5.msysgit.1

Dear James Knight,

It is rather unclear why, in the context of Buildroot, a host RPM would be needed, and why an initial RPM database would have to be setup. Can you expand on this?

Also, same comments as for beecrypt and neon.

Thanks!

Thomas

Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Thomas,

The example case I have (which I really should have provided in the commit message; sorry), is that for my target I use rpm's to provide additional modifications on my target. I use the rpm system and a specific directory to install/track and persist these modifications on said target. The workaround I had been using with the rpm system was that when installing these modification I had to use the --nodeps option. Without this option, rpm packages would not install since it couldn't find specific dependencies in the system; for example, not understanding that "/var/lib" exists or that "/bin/sh" is an available executable.

In order to avoid skipping the dependency check, I had to track these dependencies in the rpm database using another package (a "base" or "core" package). So, I would generate a rpm package which would track directories and executables required for any modification to depend on and install that package in the post-build phase. This would provide a target image which my "core" package installed and the user would automatically be ready to install additional software packages.

Now, my first attempts were just to build and install my "core" rpm package using my host system's rpm package. That didn't work since my rpm-support on my Fedora system (4.12) doesn't generate the same rpm database format used by the current rpm package version found in Buildroot (5.2). Hence, I needed a host variant of rpm to match my target system's rpm to produce a correct initial database.

You're absolutely correct. I got caught up in the mindset that "I need to make my host rpm package match exactly to my variant rpm package" (based on my previous point I mentioned above). I can go ahead and update this patch (along with beecrypt and neon) to remove any host variant make definitions depend on BR2_PACKAGE_* configuration options (if you still feel the host variant modifications are still useful).

That being said, I worry about the case where a developer builds the host variant and target variant rpm package with different settings. For example, a target system has a built rpm package without bzip2 support and the host variant does support it. Now the responsibility of ensuring not to compress built packages via bzip2 is now passed off to other developers; something I'd like to avoid. When setting up a configuration, I'd rather just have the option to configure my host variant rpm package to match capabilities found on my target variant. What I feel now is maybe I should have a host configuration item for my host rpm package indicating if it should include bzip2 support (and any other setting that really affects capabilities between the host and variant package). Thoughts?

Hi James,

An alternative solution would be to switch Buildroot to rpm 4.x (latest version is 4.12.0). The 4.x series seems to be more actively maintained than rpm5, and is the version of choice for most distros using rpm.

baruch

     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

Baruch,

Hmm... did not think of "downgrading". I guess if rpm4 was integrated into Buildroot I would not have this issue (at this point in time). After reading a bit of the upgrade-fork of rpm5, maybe it would be better to provide an rpm4 and rpm5 package. This would allow a builder to choose either the common variant over the "latest-greatest" variant. I'd be worried to just transition from rpm5 down to rpm4 in case any other developer would prefer using rpm5.

That being said, I'm wondering if its best to just drop the attempt to support a host rpm build. If its rare capability that no one really needs, I'll just apply it to my own variant and there will be less maintenance for the official Buildroot source.

Hi James,

I wouldn't call rpm5 "latest". It has forked from rpm in 2008, and is developed independently. The current Buildroot version has not been updated since 2009, quite far from "latest". Switching to latest rpm 4.x could as well be considered a "bump".

baruch

     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

Baruch, All;

After some playing around, I might be close to a patch that will "bump" from rpm5 to rpm's latest 4.12.0.1 version. I'm hoping to do a little bit more testing to cover a series of new configuration options. I guess the first question is, will anyone not like a transition from rpm5 to rpm?

That being said, the change does not help my situation of having a target-complaint rpm build. I can't guarantee that my target rpm's berkeleydb matches my host rpm's berkeleydb. If I attempt to prepare the target system's rpm database with my host (stock Fedora), I will get a "DB_VERSION_MISMATCH" error. This makes me believe, to support a post-build generation of a target system's rpm database, host support for rpm is required. With the change from rpm5 to rpm, the full list of dependent packages I'll have to provide host-support are now as
follows: beecrypt, berkeleydb, libnss and neon. I can make another attempt to push up host-support changes for these packages (along with rpm) with corrections on issues Thomas has indicated; unless anyone feels that this use case is too specific for Buildroot.

On a side note, a patch request made recently by universe II indicates that some regex/pcre issues. If we do transition from rpm5 to rpm, this shouldn't be an issue as rpm uses POSIX regex's by default (PCRE regex's seem to be only supported with some manual Makefile changes).

I agree with that and I think this is a valid use case for adding a host rpm.
In this case, the host rpm should be added to Config.in.host.

If someone thinks that this is not a valid use case, then I think we should
remove the rpm package altogether.

As far as I can see, the crypto libraries are optional. For the use case you
mention, I also don't see the need to support crypto in host-rpm. Berkeleydb is mandatory but we can use the internal implementation (for host packages, that's usually OK - and actually, the current rpm package seems to use the internal implementation, which is wrong...). For neon, adding the host variant will be needed. Try with the minimally-configured host-neon, though rpm may require some of its options (e.g. WebDAV).

Regards,
Arnout

Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

Arnout,

When attempting to support rpm 4.12.0.1, I believe beecrypt is a requirement (but I can look at that again tonight; unless you're just talking about nss). Since you've mentioned that internal implementations can be fine for host builds, there is a configuration option to have an internal build of beecrypt which I can try to do (instead of trying to do a host package for beecrypt).

I saw the option to build with an internal db implementation, but I'm a bit curious what the correct way to set it up (same with beecrypt, as mentioned above). While I can set the configuration options to build these internally, I have to somehow extract/link-up the beecrypt/berkeleydb code with my host-rpm source (ie. I'll need a 'beecrypt' and 'db' folder inside my host-rpm extracted source). Is there an example out there (I'm having trouble seeing if another host package in Buildroot does this)? I really don't know how else to download and prepare beecrypt/berkeleydb without making them host-supported packages as well.

On 08/24/2015 11:08 PM, James Knight wrote:
[snip]

I haven't looked at rpm 4.12.0.1, but the rpm5 tarball we have now has the
berkeleydb sources bundled. It doesn't have beecrypt though (but according to configure.ac it's optional).

If rpm 4.12.0.1 doesn't have those sources bundled, then it's definitely better
to just add host-beecrypt and host-berkeleydb.

Regards,
Arnout

Arnout Vandecappelle      arnout dot vandecappelle at essensium dot com
Senior Embedded Software Architect . . . . . . +32-478-010353 (mobile)
Essensium, Mind division . . . . . . . . . . . . . . http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium . . . . . BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

James,

Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com