| Message ID | 1439486091-6564-3-git-send-email-james.knight@rockwellcollins.com |
|---|---|
| State | Changes Requested |
| Headers | show |
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, 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
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
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.
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
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).
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, 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.
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. >
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))
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