Hide Forgot
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.
I'll take this.
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.
> 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?
(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.
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. ;)
And the same applies to the -tcl-devel and -java-devel subpackages.
Took the words right out of my mouth.
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!
What URLs?
The same URLs should work as I haven't bumped version.
Ok, much better. APPROVED.
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?
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)?
Koji scratch build is here: http://koji.fedoraproject.org/koji/taskinfo?taskID=4052074
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.
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.
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.
If this is replacing something, it needs to Obsolete/Provide properly. https://fedoraproject.org/wiki/Packaging:Guidelines#Renaming.2FReplacing_Existing_Packages
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.
If we want everyone to move to libdb and get off db4, why ship libdb4 at all?
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.
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.
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-*
> 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. ;)
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?
(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.
(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.
> 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.
OK, thanks for for your opinions guys. Maybe I was too harsh to see libdb4 in rawhide ASAP ;-) I will add the Obsoletes.
Believe me, I understand. Let me know when that's ready.
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.
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.
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
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
Created attachment 583205 [details] proposed spec changes from comment 3 and comment 34
Sorry for delay. I'm back from holidays. The spec & src.rpm is now updated.
Spec and SRPM spec don't match, please post new, matching URLs.
It should be in sync now.
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.
To not to get this review stuck again. Could you please approve it so that I can import the package?
Absolutely, once #39 is addressed.
That's a SHOULD, and notice bottom of comment 17.
Oh, that's right. Thanks. APPROVED.
New Package SCM Request ======================= Package Name: libdb4 Short Description: This package is used as replacement for compat-db and db4. Owners: jnovy Branches: InitialCC:
Git done (by process-git-requests).
libdb4 is now built. Thanks for cooperation!
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.