Bug 816124 - Review Request: libdb4 - Oracle (Berkeley) DB package 4.x.x series
Summary: Review Request: libdb4 - Oracle (Berkeley) DB package 4.x.x series
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Gwyn Ciesla
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 225647
TreeView+ depends on / blocked
 
Reported: 2012-04-25 10:14 UTC by Jindrich Novy
Modified: 2014-05-05 11:40 UTC (History)
6 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2012-07-11 19:02:30 UTC
Type: ---
Embargoed:
gwync: fedora-review+
gwync: fedora-cvs+


Attachments (Terms of Use)
proposed spec changes from comment 3 and comment 34 (7.92 KB, patch)
2012-05-09 09:47 UTC, Michael Schwendt
no flags Details | Diff

Description Jindrich Novy 2012-04-25 10:14:55 UTC
Spec URL: http://jnovy.fedorapeople.org/libdb4.spec
SRPM URL: http://jnovy.fedorapeople.org/libdb4-4.8.30-1.fc17.src.rpm
Description:
This package is used as replacement for comap-db and db4.

The Berkeley Database (Berkeley DB) is a programmatic toolkit that
provides embedded database support for both traditional and
client/server applications. The Berkeley DB includes B+tree, Extended
Linear Hashing, Fixed and Variable-length record access methods,
transactions, locking, logging, shared memory caching, and database
recovery. The Berkeley DB supports C, C++, Java, and Perl APIs. It is
used by many applications, including Python and Perl, so this should
be installed on all systems.

Comment 1 Gwyn Ciesla 2012-04-26 14:10:37 UTC
I'll take this.

Comment 2 Gwyn Ciesla 2012-04-26 15:43:50 UTC
rpmlint output trimmed and grouped for clarity.

! rpmlint checks return: 

libdb4-cxx-devel.x86_64: W: no-dependency-on libdb4-cxx/libdb4-cxx-libs/liblibdb4-cxx
libdb4-java-devel.x86_64: W: no-dependency-on libdb4-java/libdb4-java-libs/liblibdb4-java
libdb4-tcl-devel.x86_64: W: no-dependency-on libdb4-tcl/libdb4-tcl-libs/liblibdb4-tcl

Fix?

libdb4-cxx-devel.x86_64: W: no-documentation
libdb4-devel.x86_64: W: no-documentation
libdb4-devel-static.x86_64: W: no-documentation
The package contains no documentation (README, doc, etc). You have to include
documentation files.

Fix if possible.

libdb4-devel-doc.x86_64: E: devel-dependency libdb4-devel
Your package has a dependency on a devel package but it's not a devel package
itself.

Ignore.

libdb4-devel-doc.x86_64: W: wrong-file-end-of-line-encoding /usr/share/doc/libdb4-devel-doc-4.8.30/csharp/scripts/Dropdown.js
libdb4-devel-doc.x86_64: W: wrong-file-end-of-line-encoding /usr/share/doc/libdb4-devel-doc-4.8.30/csharp/FillNode.aspx
libdb4-devel-doc.x86_64: W: wrong-file-end-of-line-encoding /usr/share/doc/libdb4-devel-doc-4.8.30/csharp/styles/Presentation.css
libdb4-devel-doc.x86_64: W: wrong-file-end-of-line-encoding /usr/share/doc/libdb4-devel-doc-4.8.30/csharp/SearchHelp.aspx
libdb4-devel-doc.x86_64: W: wrong-file-end-of-line-encoding /usr/share/doc/libdb4-devel-doc-4.8.30/csharp/scripts/EventUtilities.js
libdb4-devel-doc.x86_64: W: wrong-file-end-of-line-encoding /usr/share/doc/libdb4-devel-doc-4.8.30/csharp/scripts/script_feedBack.js
libdb4-devel-doc.x86_64: W: wrong-file-end-of-line-encoding /usr/share/doc/libdb4-devel-doc-4.8.30/csharp/Web.Config
libdb4-devel-doc.x86_64: W: wrong-file-end-of-line-encoding /usr/share/doc/libdb4-devel-doc-4.8.30/csharp/scripts/CheckboxMenu.js
libdb4-devel-doc.x86_64: W: wrong-file-end-of-line-encoding /usr/share/doc/libdb4-devel-doc-4.8.30/csharp/WebTOC.xml
libdb4-devel-doc.x86_64: W: wrong-file-end-of-line-encoding /usr/share/doc/libdb4-devel-doc-4.8.30/csharp/Index.aspx
libdb4-devel-doc.x86_64: W: wrong-file-end-of-line-encoding /usr/share/doc/libdb4-devel-doc-4.8.30/csharp/styles/highlight.css
libdb4-devel-doc.x86_64: W: wrong-file-end-of-line-encoding /usr/share/doc/libdb4-devel-doc-4.8.30/csharp/LoadIndexKeywords.aspx
libdb4-devel-doc.x86_64: W: wrong-file-end-of-line-encoding /usr/share/doc/libdb4-devel-doc-4.8.30/csharp/WebKI.xml
libdb4-devel-doc.x86_64: W: wrong-file-end-of-line-encoding /usr/share/doc/libdb4-devel-doc-4.8.30/csharp/scripts/highlight.js
libdb4-devel-doc.x86_64: W: wrong-file-end-of-line-encoding /usr/share/doc/libdb4-devel-doc-4.8.30/csharp/scripts/SplitScreen.js
libdb4-devel-doc.x86_64: W: wrong-file-end-of-line-encoding /usr/share/doc/libdb4-devel-doc-4.8.30/csharp/scripts/script_manifold.js
libdb4-devel-doc.x86_64: W: wrong-file-end-of-line-encoding /usr/share/doc/libdb4-devel-doc-4.8.30/csharp/TOC.css
libdb4-devel-doc.x86_64: W: wrong-file-end-of-line-encoding /usr/share/doc/libdb4-devel-doc-4.8.30/csharp/scripts/CommonUtilities.js
libdb4-devel-doc.x86_64: W: wrong-file-end-of-line-encoding /usr/share/doc/libdb4-devel-doc-4.8.30/csharp/styles/Whidbey/presentation.css
libdb4-devel-doc.x86_64: W: wrong-file-end-of-line-encoding /usr/share/doc/libdb4-devel-doc-4.8.30/csharp/TOC.js
This file has wrong end-of-line encoding, usually caused by creation or
modification on a non-Unix system. It could prevent it from being displayed
correctly in some circumstances.

Fix.

libdb4-devel-static.x86_64: W: spelling-error %description -l en_US statical -> statically, statistical, statistic
The value of this tag appears to be misspelled. Please double-check.

Change statical to static.

libdb4-tcl-devel.x86_64: W: no-documentation
libdb4-utils.x86_64: W: no-documentation
The package contains no documentation (README, doc, etc). You have to include
documentation files.

Fix if feasible.

libdb4-utils.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/db4_recover ['/usr/lib64']
libdb4-utils.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/db4_verify ['/usr/lib64']
libdb4-utils.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/db4_stat ['/usr/lib64']
libdb4-utils.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/db4_checkpoint ['/usr/lib64']
libdb4-utils.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/db4_load ['/usr/lib64']
libdb4-utils.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/db4_hotbackup ['/usr/lib64']
libdb4-utils.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/db4_archive ['/usr/lib64']
libdb4-utils.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/db4_dump ['/usr/lib64']
libdb4-utils.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/db4_sql ['/usr/lib64']
libdb4-utils.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/db4_deadlock ['/usr/lib64']
libdb4-utils.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/db4_printlog ['/usr/lib64']
libdb4-utils.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/db4_upgrade ['/usr/lib64']
The binary or shared library defines `RPATH'. Usually this is a bad thing
because it hardcodes the path to search libraries and so makes it difficult to
move libraries around.  Most likely you will find a Makefile with a line like:
gcc test.o -o test -Wl,--rpath.  Also, sometimes configure scripts provide a
--disable-rpath flag to avoid this.

Fix.

libdb4-utils.x86_64: W: no-manual-page-for-binary db4_sql
libdb4-utils.x86_64: W: no-manual-page-for-binary db4_archive
libdb4-utils.x86_64: W: no-manual-page-for-binary db4_printlog
libdb4-utils.x86_64: W: no-manual-page-for-binary db4_recover
libdb4-utils.x86_64: W: no-manual-page-for-binary db4_dump
libdb4-utils.x86_64: W: no-manual-page-for-binary db4_dump185
libdb4-utils.x86_64: W: no-manual-page-for-binary db4_hotbackup
libdb4-utils.x86_64: W: no-manual-page-for-binary db4_checkpoint
libdb4-utils.x86_64: W: no-manual-page-for-binary db4_load
libdb4-utils.x86_64: W: no-manual-page-for-binary db4_upgrade
libdb4-utils.x86_64: W: no-manual-page-for-binary db4_verify
libdb4-utils.x86_64: W: no-manual-page-for-binary db4_deadlock
libdb4-utils.x86_64: W: no-manual-page-for-binary db4_stat

Fix if feasible.

- package meets naming guidelines
- package meets packaging guidelines
- license ( Sleepycat and BSD ) OK, text in %doc, matches source
- spec file legible, in am. english
- source matches upstream
- package compiles on devel (x86_64)
- no missing BR
- no unnecessary BR
- no locales
- not relocatable
- owns all directories that it creates
- no duplicate files
- permissions ok
- %clean ok
- macro use consistent
- code, not content
- no need for -docs
- nothing in %doc affects runtime
- no need for .desktop file
- devel package ok
- no .la files
- post/postun ldconfig ok
- devel requires base package n-v-r 

Pretty good, and I'm not sure what of the above is fixable given that it's older code, but what can needs to be.

Comment 3 Michael Schwendt 2012-04-26 19:40:46 UTC
> libdb4-devel-doc.x86_64: E: devel-dependency libdb4-devel
> Your package has a dependency on a devel package but it's not
> a devel package itself.
> 
> Ignore.

Please don't ignore, but remove the dependencies.

    | %package devel-doc
    | Summary: C development documentation files for the Berkeley DB library
    | Group: Development/Libraries
<!> | Requires: %{name} = %{version}-%{release}
<!> | Requires: %{name}-devel = %{version}-%{release}

Documentation packages are supposed to be installable independent of a base package or its -devel package. Documentation packages also belong into group "Documentation".


> - devel package ok
> - post/postun ldconfig ok

Dubious. Please revisit. Where are the run-time libs for the -tcl-devel and -java-devel subpackages? And running ldconfig for -devel packages is highly dubious.


> Requires: %{name}-cxx = %{version}-%{release}

Where can this -cxx subpackage be found?

Comment 4 Gwyn Ciesla 2012-04-26 19:53:08 UTC
(In reply to comment #3)
> > libdb4-devel-doc.x86_64: E: devel-dependency libdb4-devel
> > Your package has a dependency on a devel package but it's not
> > a devel package itself.
> > 
> > Ignore.
> 
> Please don't ignore, but remove the dependencies.
>
>     | %package devel-doc
>     | Summary: C development documentation files for the Berkeley DB library
>     | Group: Development/Libraries
> <!> | Requires: %{name} = %{version}-%{release}
> <!> | Requires: %{name}-devel = %{version}-%{release}
> 
> Documentation packages are supposed to be installable independent of a base
> package or its -devel package. Documentation packages also belong into group
> "Documentation".

Good point.
 
> 
> > - devel package ok
> > - post/postun ldconfig ok
> 
> Dubious. Please revisit. Where are the run-time libs for the -tcl-devel and
> -java-devel subpackages? And running ldconfig for -devel packages is highly
> dubious.
> 
See below
> 
> > Requires: %{name}-cxx = %{version}-%{release}
> 
> Where can this -cxx subpackage be found?

Good question.  I see db4-cxx out there, but no equivalent here.  If this was removed on purpose, drop the requires.  It looks like all the run-time libs are missing.

Comment 5 Michael Schwendt 2012-04-26 19:55:58 UTC
Answering my last question myself:

> %files cxx-devel
> %defattr(-,root,root,-)
> %{_libdir}/libdb_cxx.so
> %{_libdir}/libdb_cxx-%{__soversion}.so

That's a mispackage shared lib. libdb_cxx.so is the file (softlink) to be
stored in the -cxx-devel package, whereas libdb_cxx-%{__soversion}.so is the
run-time lib that belongs into a -cxx subpackage, which is missing, however.

The guidelines have been updated sometime this year in an attempt to give some background, too: https://fedoraproject.org/wiki/Packaging:Guidelines#Devel_Packages

Rule of thumb: Don't simply place all .so files in -devel packages, but place them in the package they belong into. ;)

Comment 6 Michael Schwendt 2012-04-26 19:56:40 UTC
And the same applies to the -tcl-devel and -java-devel subpackages.

Comment 7 Gwyn Ciesla 2012-04-26 19:59:59 UTC
Took the words right out of my mouth.

Comment 8 Jindrich Novy 2012-05-03 17:46:22 UTC
Sorry for delay. I just uploaded the fixed spec and packages. I didn't care much about documenation in -devel packages otherwise it should be OK. If not then let me know, Thanks!

Comment 9 Gwyn Ciesla 2012-05-03 18:04:25 UTC
What URLs?

Comment 10 Jindrich Novy 2012-05-03 18:32:10 UTC
The same URLs should work as I haven't bumped version.

Comment 11 Gwyn Ciesla 2012-05-03 20:10:33 UTC
Ok, much better.  APPROVED.

Comment 12 Michael Schwendt 2012-05-03 20:59:34 UTC
Has a test-build in koji been done yet? And rpmlint output for it?


Now that the shared libs have been moved to their correct subpkgs, a closer look at the result of lines such as the following would be needed:

> # XXX Nuke non-versioned archives and symlinks
> rm -f ${RPM_BUILD_ROOT}%{_libdir}/{libdb.a,libdb_cxx.a}
> rm -f ${RPM_BUILD_ROOT}%{_libdir}/libdb-%{__soversion_major}.so
> rm -f ${RPM_BUILD_ROOT}%{_libdir}/libdb_cxx-%{__soversion_major}.so
> rm -f ${RPM_BUILD_ROOT}%{_libdir}/libdb_tcl-%{__soversion_major}.so

Just based on the spec file, one cannot guess what SONAMEs are involved and what ldconfig will do to these installed files. 

The comment behind the 'XXX' is far from clear. It's a basic programmer's mistake to not answer the "Why?" but only repeat the "What?" in a comment. The spec file would be more comprehensible, if it explained _why_ these installed files are deleted.

Further, 

> rm -f ${RPM_BUILD_ROOT}%{_libdir}/libdb_tcl.so

With this, no -ldb_tcl is possible anymore. Contrary to

> %{_libdir}/libdb-%{__soversion}.so
> %{_libdir}/libdb.so

> %{_libdir}/libdb_cxx-%{__soversion}.so
> %{_libdir}/libdb_cxx.so

in the other packages.


* There is no libdb4-tcl-devel package?


The subpackages do

> Requires: %{name} = %{version}-%{release}

which is not arch-specific:
https://fedoraproject.org/wiki/Packaging:Guidelines#Requiring_Base_Package


> %files cxx-devel
> %defattr(-,root,root,-)
> %{_libdir}/libdb_cxx.so
> %{_includedir}/%{name}/db_cxx.h

The includedir is unowned.



> This package is used as replacement for comap-db and db4.

And no Obsoletes/Provides as would be normal for a replacement package?

Comment 13 Michael Schwendt 2012-05-03 21:15:26 UTC
Answering some of my questions/concerns myself:

# yum list db4\*|grep ^db
db4.x86_64                          4.8.30-10.fc17              @updates-testing
db4.i686                            4.8.30-10.fc17              updates-testing 
db4-cxx.i686                        4.8.30-10.fc17              updates-testing 
db4-cxx.x86_64                      4.8.30-10.fc17              updates-testing 
db4-devel.i686                      4.8.30-10.fc17              updates-testing 
db4-devel.x86_64                    4.8.30-10.fc17              updates-testing 
db4-devel-static.x86_64             4.8.30-10.fc17              updates-testing 
db4-java.i686                       4.8.30-10.fc17              updates-testing 
db4-java.x86_64                     4.8.30-10.fc17              updates-testing 
db4-tcl.x86_64                      4.8.30-10.fc17              updates-testing 
db4-utils.x86_64                    4.8.30-10.fc17              updates-testing 

 => Plenty of packages to handle with proper Obsolete/Provides.


$ ldconfig -p|grep db-4
	libdb-4.8.so (libc6,x86-64) => /lib64/libdb-4.8.so

So, apparently, nothing uses/needs libdb-4.so (not even for -ldb-4)?

Comment 14 Jindrich Novy 2012-05-04 07:59:03 UTC
Koji scratch build is here:

http://koji.fedoraproject.org/koji/taskinfo?taskID=4052074

Comment 15 Michael Schwendt 2012-05-04 10:40:44 UTC
Then comment 12 and comment 13 hold true.

[...]

A look at the built rpms also confirms the inconsistencies:

$ rpmls -p libdb4-java-4.8.30-1.fc18.x86_64.rpm|grep lib64
-rwxr-xr-x  /usr/lib64/libdb_java-4.8.so
lrwxrwxrwx  /usr/lib64/libdb_java-4.8_g.so
lrwxrwxrwx  /usr/lib64/libdb_java-4.so
lrwxrwxrwx  /usr/lib64/libdb_java.so

Compared with your 'XXX Nuke...' comment in the spec you here include both the unversioned development-only symlink as well as the major-version-only symlink to the library.

Comment 16 Gwyn Ciesla 2012-05-04 12:28:28 UTC
Good catches, Michael, this will teach me to work on reviews while extremely busy.  Temporarily un-approved.

The Obsoletes/Provides most definitely need fixing, and I share Michael's curiosity about the unversioned links, etc.

Comment 17 Jindrich Novy 2012-05-04 12:43:41 UTC
Packages are now updated. The nonversioned and major versioned libraries are now gone.

Jon, Obsoletes is intentionally broken so that libdb users will need to decide whether they need libdb4 or libdb. db4 and compat-db will be gone so no need to provide/obsolete them.

Comment 18 Gwyn Ciesla 2012-05-04 12:59:16 UTC
If this is replacing something, it needs to Obsolete/Provide properly.

https://fedoraproject.org/wiki/Packaging:Guidelines#Renaming.2FReplacing_Existing_Packages

Comment 19 Jindrich Novy 2012-05-04 13:11:06 UTC
These policies do not fit to the purpose of this new package.

Many libdb dependent packages have dependencies to db4 (and db4-devel) just because the package just needs libdb and package maintainers do not know there exist "libdb" package which ships non-obsolete version.

Note it is properly communicated on fedora-devel. The plan is to remove compat-db and db4 and introduce libdb4 package which will break deps of all db4* packages so that maintainers are to decide whether they need libdb ver. 4 or 5 and rebuild their package against one of these.

If libdb4 correctly obsoletes db4 and compat-db then nothing happens and we end up with dozens of packages dependent on obsolete libdb for no reason shipping libdb4 forever.

Comment 20 Gwyn Ciesla 2012-05-04 13:15:54 UTC
If we want everyone to move to libdb and get off db4, why ship libdb4 at all?

Comment 21 Jindrich Novy 2012-05-04 13:25:34 UTC
The reason is that there still might be good reasons for keeping libdb4 in cases such as openldap, build problems against libdb5, compatibility, etc. It should be the case only of minority of libdb dependent packages but it is still worth doing.

This step of introduction of libdb4 is necessary because if I just remove compat-db and db4 I would likely make some apps unrebuildable and need to introduce libdb4 anyway.

Also, some third parties (apps not present in Fedora) might still require libdb4.

If it turns out libdb4 is not needed I will happily dead-package it as soon as it proves true.

Comment 22 Michael Schwendt 2012-05-04 13:30:58 UTC
Not true.

You could simply follow the guidelines nevertheless,

| If a package supersedes/replaces an existing package without being
| a compatible enough replacement as defined in above, use only the
| Obsoletes from above.

and _either_ add these Obsoletes (_only_ Obsoletes, no Provides!) tags to the new libdb4 packages _or_ your libdb packages. Doing the latter would have the benefit of nuking installed db4* packages, if they are not needed anymore in dependencies.

Comment 23 Michael Schwendt 2012-05-04 13:32:31 UTC
Dependencies, which still want/need to build with db4 _explicitly_, will continue to work, and may continue to build after updating their BuildRequires from db4-* to libdb4-*

Comment 24 Michael Schwendt 2012-05-04 13:35:22 UTC
> The plan is to remove compat-db and db4 and introduce libdb4 package
> which will break deps of all db4* packages

That won't work out completely, btw because so far, your libdb4* builds don't "break deps", at least not the automatic deps on SONAMEs. Just any explicit [Build]Requires. ;)

Comment 25 Gwyn Ciesla 2012-05-04 13:39:45 UTC
I understand the impetus, but instead of breaking lots of things, would it not be friendlier to do a repoquery, file some bugs, and do some test builds against libdb5?

Comment 26 Jindrich Novy 2012-05-04 13:42:43 UTC
(In reply to comment #24)
> > The plan is to remove compat-db and db4 and introduce libdb4 package
> > which will break deps of all db4* packages
> 
> That won't work out completely, btw because so far, your libdb4* builds don't
> "break deps", at least not the automatic deps on SONAMEs. Just any explicit
> [Build]Requires. ;)

True but what it's important here is that package maintainer will not be able to rebuild his package just with BR: db4-devel so he will need to adjust it manually, i.e. select either libdb or libdb4.

Comment 27 Jindrich Novy 2012-05-04 13:45:19 UTC
(In reply to comment #25)
> I understand the impetus, but instead of breaking lots of things, would it not
> be friendlier to do a repoquery, file some bugs, and do some test builds
> against libdb5?

Nope. The problem is that Fedora is also a bit weird from the Berkeley DB package naming. jbj named the packages very inconveniently. No other distro has db4 or compat-db. Most of them just have libdb or libdbX.

Comment 28 Michael Schwendt 2012-05-04 14:37:42 UTC
> he will need to adjust it manually, i.e. select either libdb or libdb4.

Which is okay. And the lazy packager will simply s/db4/libdb4/ in the BuildRequires and stick to db4 instead of evaluating whether v5 could be used instead. ;)

Anyway: You must add the Obsoletes (for all [sub]packages) to either libdb4* or libdb*. Upgrade path sanity. Else you introduce implicit conflicts with old and already installed db4* packages.

Comment 29 Jindrich Novy 2012-05-04 15:17:58 UTC
OK, thanks for for your opinions guys. Maybe I was too harsh to see libdb4 in rawhide ASAP ;-) I will add the Obsoletes.

Comment 30 Gwyn Ciesla 2012-05-04 16:06:23 UTC
Believe me, I understand.  Let me know when that's ready.

Comment 31 Michael Schwendt 2012-05-04 18:00:50 UTC
libdb.spec in Rawhide git is a mess, unfortunately, and will need all (if not even more) fixes as this libdb4 package.

In particular the placement of the versioned (!) *.so files in -devel package makes no sense. But it's not limited to that. Major changes to the packages are needed.

Comment 32 Jindrich Novy 2012-05-06 12:28:20 UTC
The new packages with new obsoletes for db4 are now uploaded.

I need to also rework the main libdb package. It will be pretty similar to libdb4 I guess.

Comment 33 Gwyn Ciesla 2012-05-07 15:43:42 UTC
Now we have:

libdb4.src:274: W: macro-in-comment %{_libdir}
libdb4.src:274: W: macro-in-comment %{__soversion_major}
libdb4.src:274: W: macro-in-comment %{__soversion_major}
libdb4.src:274: W: macro-in-comment %{__soversion_major}
libdb4.src:274: W: macro-in-comment %{__soversion_major}
libdb4.src:392: W: macro-in-comment %{_libdir}
libdb4.src:392: W: macro-in-comment %{__soversion}
There is a unescaped macro after a shell style comment in the specfile. Macros
are expanded everywhere, so check if it can cause a problem in this case and
escape the macro with another leading % if appropriate.

libdb4.x86_64: W: obsolete-not-provided db4
libdb4-cxx.x86_64: W: obsolete-not-provided db4-cxx
libdb4-cxx-devel.x86_64: W: obsolete-not-provided db4-cxx-devel
libdb4-devel.x86_64: W: obsolete-not-provided db4-devel
libdb4-devel-static.x86_64: W: obsolete-not-provided db4-devel-static
libdb4-java.x86_64: W: obsolete-not-provided db4-java
libdb4-tcl.x86_64: W: obsolete-not-provided db4-tcl
libdb4-utils.x86_64: W: obsolete-not-provided db4-utils
If a package is obsoleted by a compatible replacement, the obsoleted package
should also be provided in order to not cause unnecessary dependency breakage.
If the obsoleting package is not a compatible replacement for the old one,
leave out the Provides.

libdb4-tcl-devel.x86_64: W: no-dependency-on libdb4-tcl/libdb4-tcl-libs/liblibdb4-tcl

Comment 34 Michael Schwendt 2012-05-07 20:56:03 UTC
The questionable -devel-doc subpackage and its superfluous dependencies ought to be fixed, too. The package includes much more than just C API docs. It's low-hanging fruit to rename it to just -doc especially when Obsoletes are introduced anyway.

I've summed up some breakage that has piled up in the libdb package: bug 819079

Comment 35 Michael Schwendt 2012-05-09 09:47:18 UTC
Created attachment 583205 [details]
proposed spec changes from comment 3 and comment 34

Comment 36 Jindrich Novy 2012-06-21 18:47:04 UTC
Sorry for delay. I'm back from holidays. The spec & src.rpm is now updated.

Comment 37 Gwyn Ciesla 2012-06-21 18:55:38 UTC
Spec and SRPM spec don't match, please post new, matching URLs.

Comment 38 Jindrich Novy 2012-06-21 19:46:22 UTC
It should be in sync now.

Comment 39 Gwyn Ciesla 2012-06-22 14:44:32 UTC
Now it's just:

ibdb4.x86_64: W: obsolete-not-provided db4
libdb4-cxx.x86_64: W: obsolete-not-provided db4-cxx
libdb4-cxx-devel.x86_64: W: obsolete-not-provided db4-cxx-devel
libdb4-devel.x86_64: W: obsolete-not-provided db4-devel
libdb4-devel-static.x86_64: W: obsolete-not-provided db4-devel-static
libdb4-java.x86_64: W: obsolete-not-provided db4-java
libdb4-tcl.x86_64: W: obsolete-not-provided db4-tcl
libdb4-utils.x86_64: W: obsolete-not-provided db4-utils
If a package is obsoleted by a compatible replacement, the obsoleted package
should also be provided in order to not cause unnecessary dependency breakage.
If the obsoleting package is not a compatible replacement for the old one,
leave out the Provides.

Comment 40 Jindrich Novy 2012-07-03 07:38:16 UTC
To not to get this review stuck again. Could you please approve it so that I can import the package?

Comment 41 Gwyn Ciesla 2012-07-03 11:51:02 UTC
Absolutely, once #39 is addressed.

Comment 42 Michael Schwendt 2012-07-03 12:16:50 UTC
That's a SHOULD, and notice bottom of comment 17.

Comment 43 Gwyn Ciesla 2012-07-03 12:27:14 UTC
Oh, that's right.  Thanks.

APPROVED.

Comment 44 Jindrich Novy 2012-07-10 04:57:39 UTC
New Package SCM Request
=======================
Package Name: libdb4
Short Description: This package is used as replacement for compat-db and db4.
Owners: jnovy
Branches: 
InitialCC:

Comment 45 Kevin Fenzi 2012-07-10 22:27:10 UTC
Git done (by process-git-requests).

Comment 46 Jindrich Novy 2012-07-11 19:02:30 UTC
libdb4 is now built. Thanks for cooperation!

Comment 47 Björn Esser (besser82) 2014-05-04 14:56:49 UTC
Package Change Request
======================
Package Name: libdb4
New Branches: el5 epel7
Owners: besser82 lupinix

We need these branches to prepare the dependencies for (back-)porting Python3 to EPEL.

Comment 48 Gwyn Ciesla 2014-05-05 11:40:38 UTC
Git done (by process-git-requests).


Note You need to log in before you can comment on or make changes to this bug.