Re: [Rpm-maint] [rpm-software-management/rpm] Check for 'gettext' during configure script (#245)

[Jeff Johnson]

Did you build with --disable-nls? There is no way for RPM configure to guess 
whether uninstalled get text is bug of a feature: YMMV, everyone's does.

```
 ./configure --help | grep nls
  --disable-nls   do not use Native Language Support
```

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/245#issuecomment-312411263___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

[Rpm-maint] [rpm-software-management/rpm] Check for 'gettext' during configure script (#245)

[Ryan Whitworth]

Output from configure script is invalid when gettext is not installed.  
Installing gettext after the fact also doesn't resolve the problem until 
configure is re-ran.  I believe the configure script should detect when gettext 
is missing and error appropriately.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/245___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

[Rpm-maint] [rpm-software-management/rpm] How to run unit tests (#243)

[Jun Aruga]

I want to run unit tests under `tests/` directory.

I tried below way seeing `INSTALL` document
https://github.com/rpm-software-management/rpm/blob/master/INSTALL#L181-L186

```
$ make check
make  check-recursive
make[1]: Entering directory '/home/jaruga/git/rpm'
Making check in po
make[2]: Entering directory '/home/jaruga/git/rpm/po'
make[2]: Nothing to be done for 'check'.
make[2]: Leaving directory '/home/jaruga/git/rpm/po'
Making check in misc
make[2]: Entering directory '/home/jaruga/git/rpm/misc'
make[2]: Nothing to be done for 'check'.
make[2]: Leaving directory '/home/jaruga/git/rpm/misc'
Making check in luaext
make[2]: Entering directory '/home/jaruga/git/rpm/luaext'
make[2]: Nothing to be done for 'check'.
make[2]: Leaving directory '/home/jaruga/git/rpm/luaext'
Making check in rpmio
make[2]: Entering directory '/home/jaruga/git/rpm/rpmio'
make  
make[3]: Entering directory '/home/jaruga/git/rpm/rpmio'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/home/jaruga/git/rpm/rpmio'
make[2]: Leaving directory '/home/jaruga/git/rpm/rpmio'
Making check in lib
make[2]: Entering directory '/home/jaruga/git/rpm/lib'
make  check-am
make[3]: Entering directory '/home/jaruga/git/rpm/lib'
make  
make[4]: Entering directory '/home/jaruga/git/rpm/lib'
make  all-am
make[5]: Entering directory '/home/jaruga/git/rpm/lib'
make[5]: Nothing to be done for 'all-am'.
make[5]: Leaving directory '/home/jaruga/git/rpm/lib'
make[4]: Leaving directory '/home/jaruga/git/rpm/lib'
make[3]: Leaving directory '/home/jaruga/git/rpm/lib'
make[2]: Leaving directory '/home/jaruga/git/rpm/lib'
Making check in sign
make[2]: Entering directory '/home/jaruga/git/rpm/sign'
make[2]: Nothing to be done for 'check'.
make[2]: Leaving directory '/home/jaruga/git/rpm/sign'
Making check in build
make[2]: Entering directory '/home/jaruga/git/rpm/build'
make[2]: Nothing to be done for 'check'.
make[2]: Leaving directory '/home/jaruga/git/rpm/build'
Making check in scripts
make[2]: Entering directory '/home/jaruga/git/rpm/scripts'
make[2]: Nothing to be done for 'check'.
make[2]: Leaving directory '/home/jaruga/git/rpm/scripts'
Making check in fileattrs
make[2]: Entering directory '/home/jaruga/git/rpm/fileattrs'
make[2]: Nothing to be done for 'check'.
make[2]: Leaving directory '/home/jaruga/git/rpm/fileattrs'
Making check in doc
make[2]: Entering directory '/home/jaruga/git/rpm/doc'
make[2]: Nothing to be done for 'check'.
make[2]: Leaving directory '/home/jaruga/git/rpm/doc'
Making check in .
make[2]: Entering directory '/home/jaruga/git/rpm'
make[2]: Leaving directory '/home/jaruga/git/rpm'
Making check in plugins
make[2]: Entering directory '/home/jaruga/git/rpm/plugins'
make[2]: Nothing to be done for 'check'.
make[2]: Leaving directory '/home/jaruga/git/rpm/plugins'
make[1]: Leaving directory '/home/jaruga/git/rpm'
```

I expected below kind of result. My way is correct?
https://github.com/rpm-software-management/rpm/issues/170#issue-211735874

Also the `fakechroot` URL https://github.com/fakechroot in the document is 
correct? The URL is just a user's page.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/243___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [PATCH] RFC: Allow for disabling Berkeley DB support

[Darren Hart]

On Fri, Jun 30, 2017 at 10:57:05AM +0100, Neal Gompa wrote:

...

> My suggestion is to assume enabled (unless dependencies can't be
> satisfied) if not specified to be disabled. If specified to be enabled
> and dependencies not satisfied, throw an error.
> 

I did not want to change the default behavior of ndb support, which is
currently disabled by default. That accounts for the bulk of the inverted
configure.ac logic in the patch(es).

So this series assumes --enabled-bdb and --disable-ndb, unless otherwise
specified. It will fail configure if bdb is enabled and the dependencies
(internal or external) are not satisfied, or if no database backend is enabled.

I think I should leave it to the ndb developers to determine when ndb is ready
to be enabled by default.

-- 
Darren Hart
VMware Open Source Technology Center
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [PATCH] RFC: Allow for disabling Berkeley DB support

[Neal Gompa]

On Fri, Jun 30, 2017 at 12:38 AM, Darren Hart  wrote:
> On Thu, Jun 29, 2017 at 08:33:46AM +0100, Neal Gompa wrote:
>> On Thu, Jun 22, 2017 at 10:20 PM, Darren Hart (VMware)
>>  wrote:
>> > Introduce a --disable-bdb configuration option which disables the use of
>> > Berkeley DB entirely. Update the various autotools to ensure that at
>> > least one of BDB or NDB is enabled. Existing configuration options
>> > continue as before. Minor updates to dbi.h and dbi.c to handle bdb being
>> > optional. Add a little extra paranoia to dbi.c which will error out of
>> > the build if neither BDB nor NDB are enabled (which should not be
>> > possible to configure).
>> >
>> > Signed-off-by: Darren Hart (VMware) 
>>
>> So, I tested this patch against rpm git master on MacOS, and while the
>> --enable/--disable for ndb and bdb works when one of them are enabled,
>> the case when both are disabled is surprising. Since your patch
>> doesn't validate the acceptable conditions at the configure.ac level,
>> it accepts it and attempts to build ndb... which fails because missing
>> things on macOS, but that's a different issue.
>>
>> The patch is basically mostly okay, but I would really like to see the
>> configure.ac have logic that prevents creating the makefiles and
>> whatnot if both available rpmdb backends are disabled.
>
> Thanks for testing the patch.
>
> The intent behind the patch is to allow for the following configurations:
>
> bdb
> ndb
> bdb+ndb
>
> If you disable bdb, it forces the enabling of ndb - similar to how if you do
> nothing, bdb is automatically selected.
>
> I did not consider the following case:
>
> --disable-bdb --disable-ndb
>
> Which I believe the is the case you are describing. The behavior there would 
> be
> as you describe, since --disable-bdb forces --enable-bdb.
>
> What would you consider to be the correct behavior in this case? Error out of
> configure with a message like "Error: At least one of bdb or ndb must be
> configured" ?
>
> Consider the following, where y=--enable, n=--disable, and - = no argument
> specified. This represents the intention of the patch:
>
> CURRENT PATCH BEHAVIOR
> bdb ndb result
> ---
> y   y   build bdb and ndb
> y   n   build bdb
> y   -   build bdb
> n   y   build ndb
> n   n   build ndb
> n   -   build ndb
> -   y   build ndb
> -   n   build bdb
> -   -   build bdb
>
> How would you suggest I update the behavior? Something like this?:
>
> PROPOSED PATCH BEHAVIOR
> bdb ndb result
> ---
> y   y   build bdb and ndb
> y   n   build bdb
> y   -   build bdb
> n   y   build ndb
> n   n   configure: error: at least one of bdb or ndb must be enabled
> n   -   configure: error: at least one of bdb or ndb must be enabled
> -   y   build bdb and ndb
> -   n   build bdb
> -   -   build bdb
>
> The above will do no automatic configuration of ndb based on the state of bdb.
>
> The following patch, applied on top of this RFC patch, implements this change,
> and configure behaves as follows under the following conditions:
>
> ./configure --disable-bdb
> ...
> checking database backends enabled... none
> configure: error: at least one of bdb or ndb must be enabled
> ...
>
> ./configure --disable-bdb --disable-ndb
> ...
> checking database backends enabled... none
> configure: error: at least one of bdb or ndb must be enabled
> ...
>
> ./configure
> ...
> checking database backends enabled... bdb
> ...
>
> ./configure --enable-ndb
> ...
> checking database backends enabled... bdb ndb
> ...
>
> ./configure --disable-bdb --enable-ndb
> ...
> checking database backends enabled... ndb
> ...
>
> Is this preferable? If so, I'll roll them together and resubmit as a v2.o
>
>
> Since this configuration appears to never have been tested, ss there an
> automated battery of tests we can run a "--disable-bdb --enable-ndb" build
> against?
>
>
> From 74ff641eee0c372396e8610dcda26c4a4e0a9896 Mon Sep 17 00:00:00 2001
> From: "Darren Hart (VMware)" 
> Date: Thu, 29 Jun 2017 16:32:38 -0700
> Subject: [PATCH] RFC: Enforce at least one of bdb or ndb in configure.ac
>
> Rather than automatically configuring ndb if bdb is disabled, exit with
> a configure error if at least one of bdb or ndb is not enabled.
>
> Add an AC_MSG_CHECKING block after bdb and ndb have been processed, and
> report to the user which database backends have been enabled. Abort with
> AC_MSG_ERROR if neither are enabled.
>
> Signed-off-by: Darren Hart (VMware) 

My suggestion is to assume enabled (unless dependencies can't be
satisfied) if not specified to be disabled. If specified to be enabled
and dependencies not satisfied, throw an error.


-- 
真実はいつも一つ！/ Always, there's only one truth!