[Buildroot] [PATCH 1/3] package/beecrypt: add host variant

[Buildroot] [PATCH 1/3] package/beecrypt: add host variant

[James Knight]

Required by an upcoming host variant of the `rpm` package.

Signed-off-by: James Knight <james.knight@rockwellcollins.com>
---
 package/beecrypt/beecrypt.mk | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/package/beecrypt/beecrypt.mk b/package/beecrypt/beecrypt.mk
index cd0b4ac..0d7b360 100644
--- a/package/beecrypt/beecrypt.mk
+++ b/package/beecrypt/beecrypt.mk
@@ -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

[Buildroot] [PATCH 2/3] package/neon: add host variant

[James Knight]

Required by an upcoming host variant of the `rpm` package.

Signed-off-by: James Knight <james.knight@rockwellcollins.com>
---
 package/neon/neon.mk | 20 +++++++++++++++++++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/package/neon/neon.mk b/package/neon/neon.mk
index 0cff1a2..adfc836 100644
--- a/package/neon/neon.mk
+++ b/package/neon/neon.mk
@@ -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

[Buildroot] [PATCH 3/3] package/rpm: add host variant

[James Knight]

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.

Signed-off-by: James Knight <james.knight@rockwellcollins.com>
---
 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

diff --git a/package/Config.in.host b/package/Config.in.host
index 1e047aa..1820b20 100644
--- a/package/Config.in.host
+++ b/package/Config.in.host
@@ -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"
diff --git a/package/rpm/Config.in.host b/package/rpm/Config.in.host
new file mode 100644
index 0000000..101f62c
--- /dev/null
+++ b/package/rpm/Config.in.host
@@ -0,0 +1,6 @@
+config BR2_PACKAGE_HOST_RPM
+	bool "host rpm"
+	help
+	  The RPM package management system.
+
+	  http://rpm5.org
diff --git a/package/rpm/rpm.mk b/package/rpm/rpm.mk
index 7f346b2..c84ed04 100644
--- a/package/rpm/rpm.mk
+++ b/package/rpm/rpm.mk
@@ -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

[Buildroot] [PATCH 1/3] package/beecrypt: add host variant

[Thomas Petazzoni]

James,

On Thu, 13 Aug 2015 13:14:49 -0400, James Knight wrote:
> Required by an upcoming host variant of the `rpm` package.
> 
> Signed-off-by: James Knight <james.knight@rockwellcollins.com>
> ---
>  package/beecrypt/beecrypt.mk | 9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/package/beecrypt/beecrypt.mk b/package/beecrypt/beecrypt.mk
> index cd0b4ac..0d7b360 100644
> --- a/package/beecrypt/beecrypt.mk
> +++ b/package/beecrypt/beecrypt.mk
> @@ -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

This is really wrong. BR2_PACKAGE_BEECRYPT_CPP indicates that we want
the C++ support of Beecrypt for the target. It says nothing about what
should be done for the host variant of Beecrypt.

Target configuration options (BR2_PACKAGE_*) should not affect how host
packages are built.

Just decide if you need C++ support in host-beecrypt. If you need it,
enable it. If you don't, do not enable it. But don't make it
conditional.

Thanks,

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

[Buildroot] [PATCH 2/3] package/neon: add host variant

[Thomas Petazzoni]

Dear James Knight,

On Thu, 13 Aug 2015 13:14:50 -0400, James Knight wrote:
> Required by an upcoming host variant of the `rpm` package.
> 
> Signed-off-by: James Knight <james.knight@rockwellcollins.com>
> ---
>  package/neon/neon.mk | 20 +++++++++++++++++++-
>  1 file changed, 19 insertions(+), 1 deletion(-)

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

[Buildroot] [PATCH 3/3] package/rpm: add host variant

[Thomas Petazzoni]

Dear James Knight,

On Thu, 13 Aug 2015 13:14:51 -0400, James Knight wrote:
> 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.

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

[Buildroot] [PATCH 3/3] package/rpm: add host variant

[James Knight]

Thomas,

On Tue, Aug 18, 2015 at 5:44 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> 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?

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.

> Also, same comments as for beecrypt and neon.

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?

On Tue, Aug 18, 2015 at 5:44 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear James Knight,
>
> On Thu, 13 Aug 2015 13:14:51 -0400, James Knight wrote:
>> 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.
>
> 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

[Buildroot] [PATCH 3/3] package/rpm: add host variant

[Baruch Siach]

Hi James,

On Tue, Aug 18, 2015 at 11:12:51AM -0400, James Knight wrote:
> 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.

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 -

[Buildroot] [PATCH 3/3] package/rpm: add host variant

[James Knight]

Baruch,

On Tue, Aug 18, 2015 at 12:03 PM, Baruch Siach <baruch@tkos.co.il> wrote:
> 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

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.

[Buildroot] [PATCH 3/3] package/rpm: add host variant

[Baruch Siach]

Hi James,

On Tue, Aug 18, 2015 at 12:36:05PM -0400, James Knight wrote:
> On Tue, Aug 18, 2015 at 12:03 PM, Baruch Siach <baruch@tkos.co.il> wrote:
> > 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
> 
> 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.

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 -

[Buildroot] [PATCH 3/3] package/rpm: add host variant

[James Knight]

Baruch, All;

On Tue, Aug 18, 2015 at 1:27 PM, Baruch Siach <baruch@tkos.co.il> wrote:
>
> 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".

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).

[Buildroot] [PATCH 3/3] package/rpm: add host variant

[Arnout Vandecappelle]

On 08/24/2015 10:14 PM, James Knight wrote:
> 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. 

 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.


> 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

 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

> 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.


-- 
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

[Buildroot] [PATCH 3/3] package/rpm: add host variant

[James Knight]

Arnout,

On Mon, Aug 24, 2015 at 4:28 PM, Arnout Vandecappelle <arnout@mind.be> wrote:
> 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.

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).

> 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...).

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.

[Buildroot] [PATCH 3/3] package/rpm: add host variant

[Arnout Vandecappelle]

On 08/24/2015 11:08 PM, James Knight wrote:
[snip]
> 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). 

 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

> 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.
> 

-- 
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