Bug 739856

This is my first package and I am looking for a sponsor.

Even though the configure script outputs that it's building the backends it is not, it only does so if --with-backends is supplied. I will fix this and upload the updated files.

I will also try to put the backends into subpackages but at this point I am not sure whether that's possible.

Spec URL: http://mpreisle.fedorapeople.org/pkgs/opendbx/opendbx.spec
SRPM URL:
http://mpreisle.fedorapeople.org/pkgs/opendbx/opendbx-1.4.5-2.fc15.src.rpm

I put all the backends into separate subpackages.

Test build: http://koji.fedoraproject.org/koji/taskinfo?taskID=3364179

Unfortunately I can't take this review or sponsor you, but I've done an informal review of this package and there are a few issues you may wish to fix.

Package Review
==============

Key:
- = N/A
x = Check
! = Problem
? = Not evaluated

=== REQUIRED ITEMS ===
[X]  Package is named according to the Package Naming Guidelines.
[X]  Spec file name must match the base package %{name}, in the format %{name}.spec.
[X]  Package meets the Packaging Guidelines.

You can remove the rm -rf $RPM_BUILD_ROOT from the %install section, and the 
Requires: pkgconfig, as these are not necessary.

[X]  Package successfully compiles and builds into binary rpms on at least one supported architecture.
Tested on: Fedora 15 x86_64
[X]  Rpmlint output:

opendbx-debuginfo.x86_64: E: incorrect-fsf-address /usr/src/debug/opendbx-1.4.5/utils/argmap.hpp
opendbx-debuginfo.x86_64: E: incorrect-fsf-address /usr/src/debug/opendbx-1.4.5/utils/argmap.cpp
opendbx-firebird.x86_64: W: spelling-error Summary(en_US) backend -> backed, back end, back-end
opendbx-firebird.x86_64: W: spelling-error %description -l en_US odbx -> oxblood
opendbx-firebird.x86_64: W: spelling-error %description -l en_US init -> unit, int, nit
opendbx-firebird.x86_64: W: spelling-error %description -l en_US backend -> backed, back end, back-end
opendbx-firebird.x86_64: W: no-documentation
opendbx-firebird.x86_64: W: devel-file-in-non-devel-package /usr/lib64/opendbx/libfirebirdbackend.so
opendbx-mssql.x86_64: W: spelling-error Summary(en_US) backend -> backed, back end, back-end
opendbx-mssql.x86_64: W: spelling-error %description -l en_US odbx -> oxblood
opendbx-mssql.x86_64: W: spelling-error %description -l en_US init -> unit, int, nit
opendbx-mssql.x86_64: W: spelling-error %description -l en_US backend -> backed, back end, back-end
opendbx-mssql.x86_64: W: no-documentation
opendbx-mssql.x86_64: W: devel-file-in-non-devel-package /usr/lib64/opendbx/libmssqlbackend.so
opendbx-mysql.x86_64: W: spelling-error Summary(en_US) backend -> backed, back end, back-end
opendbx-mysql.x86_64: W: spelling-error %description -l en_US odbx -> oxblood
opendbx-mysql.x86_64: W: spelling-error %description -l en_US init -> unit, int, nit
opendbx-mysql.x86_64: W: spelling-error %description -l en_US backend -> backed, back end, back-end
opendbx-mysql.x86_64: W: no-documentation
opendbx-mysql.x86_64: W: devel-file-in-non-devel-package /usr/lib64/opendbx/libmysqlbackend.so
opendbx-postgresql.x86_64: W: spelling-error Summary(en_US) backend -> backed, back end, back-end
opendbx-postgresql.x86_64: W: spelling-error %description -l en_US odbx -> oxblood
opendbx-postgresql.x86_64: W: spelling-error %description -l en_US init -> unit, int, nit
opendbx-postgresql.x86_64: W: spelling-error %description -l en_US pgsql 
opendbx-postgresql.x86_64: W: spelling-error %description -l en_US backend -> backed, back end, back-end
opendbx-postgresql.x86_64: W: no-documentation
opendbx-postgresql.x86_64: W: devel-file-in-non-devel-package /usr/lib64/opendbx/libpgsqlbackend.so
opendbx-sqlite.x86_64: W: spelling-error Summary(en_US) backend -> backed, back end, back-end
opendbx-sqlite.x86_64: W: spelling-error %description -l en_US odbx -> oxblood
opendbx-sqlite.x86_64: W: spelling-error %description -l en_US init -> unit, int, nit
opendbx-sqlite.x86_64: W: spelling-error %description -l en_US backend -> backed, back end, back-end
opendbx-sqlite.x86_64: W: no-documentation
opendbx-sqlite.x86_64: W: devel-file-in-non-devel-package /usr/lib64/opendbx/libsqlite3backend.so
opendbx-sqlite2.x86_64: W: spelling-error Summary(en_US) backend -> backed, back end, back-end
opendbx-sqlite2.x86_64: W: spelling-error %description -l en_US odbx -> oxblood
opendbx-sqlite2.x86_64: W: spelling-error %description -l en_US init -> unit, int, nit
opendbx-sqlite2.x86_64: W: spelling-error %description -l en_US sqlite -> sq lite, sq-lite, satellite
opendbx-sqlite2.x86_64: W: spelling-error %description -l en_US backend -> backed, back end, back-end
opendbx-sqlite2.x86_64: W: no-documentation
opendbx-sqlite2.x86_64: W: devel-file-in-non-devel-package /usr/lib64/opendbx/libsqlitebackend.so
opendbx-sybase.x86_64: W: spelling-error Summary(en_US) backend -> backed, back end, back-end
opendbx-sybase.x86_64: W: spelling-error %description -l en_US odbx -> oxblood
opendbx-sybase.x86_64: W: spelling-error %description -l en_US init -> unit, int, nit
opendbx-sybase.x86_64: W: spelling-error %description -l en_US backend -> backed, back end, back-end
opendbx-sybase.x86_64: W: no-documentation
opendbx-sybase.x86_64: W: devel-file-in-non-devel-package /usr/lib64/opendbx/libsybasebackend.so
opendbx-utils.x86_64: W: spelling-error %description -l en_US odbx -> oxblood
opendbx-utils.x86_64: W: spelling-error %description -l en_US sql -> sq, sol, sq l
12 packages and 0 specfiles checked; 2 errors, 46 warnings.

You should ask upstream to fix (or even just remove) in the incorrect FSF 
mailing addresses. I think the rest of these warnings can be ignored.

I also notice those two files (util/argmap.{cpp,hpp}) have a GPL license header 
rather than an LGPL one. If this is a typo you should ask upstream to correct 
it. Otherwise the specfile should declare License: GPLv2+ as that is a stricter 
license than LGPLv2+.

[X]  Package is not relocatable.
[X]  Buildroot tag is absent
[X]  Package is licensed with an open-source compatible license and meets other legal requirements as defined in the legal section of Packaging Guidelines.
[!]  License field in the package spec file matches the actual license.
License type: LGPLv2+ but see above
[X]  If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package is included in %doc.
[X]  Spec file is legible and written in American English.
[X]  Sources used to build the package matches the upstream source, as provided in the spec URL.
MD5SUM this package    : 8347e9583d83c5186dea14f992c19dec
MD5SUM upstream package: 8347e9583d83c5186dea14f992c19dec
[X]  Package is not known to require ExcludeArch
[X]  All build dependencies are listed in BuildRequires, except for any that are listed in the exceptions section of Packaging Guidelines.
[X]  The spec file handles locales properly.
[X]  ldconfig called in %post and %postun if required.
[!]  Package must own all directories that it creates.

Nothing owns the /usr/lib64/opendbx directory. The best solution is probably to 
make all the backend subpackages which own libs under this directory to also 
own the directory itself.

[X]  Package requires other packages for directories it uses.
[X]  Package does not contain duplicates in %files.
[X]  Permissions on files are set properly.
[X]  Package has no %clean section
[X]  Package consistently uses macros.
[X]  Package contains code, or permissable content.
[-]  Large documentation files are in a -doc subpackage, if required.
[-]  Package uses nothing in %doc for runtime.
[X]  Header files in -devel subpackage, if present.
[-]  Static libraries in -devel subpackage, if present.
[X]  Development .so files in -devel subpackage, if present.
[!]  Fully versioned dependency in subpackages, if present.

As far as I can tell the backend subpackages are useless without the main 
library, so they should Require the base package. Unless upstream makes any ABI 
compatibility guarantees about mixing versions of the backend and main library, 
you should use a fully-versioned dependency to be on the safe side.

[X]  Package does not contain any libtool archives (.la).
[-]  Package contains a properly installed %{name}.desktop file if it is a GUI application.
[X]  Package does not own files or directories owned by other packages.

=== SUGGESTED ITEMS ===
[X]  Latest version is packaged.
[X]  Package does not include license text files separate from upstream.
[-]  Description and summary sections in the package spec file contains translations for supported Non-English languages, if available.
[X]  Reviewer should test that the package builds in mock.
Tested on: Fedora 15 x86_64
[?]  Package should compile and build into binary rpms on all supported architectures.
Not tested
[?]  Package functions as described.
Not tested
[-]  Scriptlets must be sane, if used.
[X]  The placement of pkgconfig(.pc) files are correct.
[-]  File based requires are sane.

The only other issue I see here is that the backend subpackages have 
auto-generated provides and requires for private libraries under 
/usr/lib64/opendbx which is not desirable. See [1] for ways to filter these 
out.

> $ rpm -q --requires --provides -p opendbx-mysql-1.4.5-2.fc15.x86_64.rpm | grep libmysqlbackend
> libmysqlbackend.so.1()(64bit)  
> libmysqlbackend.so.1()(64bit)  

[1] http://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering

(In reply to comment #4)

> You should ask upstream to fix (or even just remove) in the incorrect FSF 
> mailing addresses. I think the rest of these warnings can be ignored.

I guess you missed this one which can be fixed:

> opendbx-sqlite.x86_64: W: devel-file-in-non-devel-package
> /usr/lib64/opendbx/libsqlite3backend.so
 

> [!]  Package must own all directories that it creates.
> 
> Nothing owns the /usr/lib64/opendbx directory. The best solution is probably to 
> make all the backend subpackages which own libs under this directory to also 
> own the directory itself.

If you do so and remove just one subpackage, the whole directory will be removed. This is I believe no the desired behavior.

Please have a look at: http://fedoraproject.org/wiki/Packaging/Guidelines#File_and_Directory_Ownership

(In reply to comment #5)
> (In reply to comment #4)
> 
> > You should ask upstream to fix (or even just remove) in the incorrect FSF 
> > mailing addresses. I think the rest of these warnings can be ignored.
> 
> I guess you missed this one which can be fixed:
> 
> > opendbx-sqlite.x86_64: W: devel-file-in-non-devel-package
> > /usr/lib64/opendbx/libsqlite3backend.so

http://fedoraproject.org/wiki/Packaging/Guidelines#Devel_Packages

(In reply to comment #5)
> (In reply to comment #4)
> 
> > You should ask upstream to fix (or even just remove) in the incorrect FSF 
> > mailing addresses. I think the rest of these warnings can be ignored.
> 
> I guess you missed this one which can be fixed:
> 
> > opendbx-sqlite.x86_64: W: devel-file-in-non-devel-package
> > /usr/lib64/opendbx/libsqlite3backend.so
Is this a dlopen'ed plugin? Then this is OK and you are mislead by rpmlint being hyperactive.

> > [!]  Package must own all directories that it creates.
> > 
> > Nothing owns the /usr/lib64/opendbx directory. The best solution is probably to 
> > make all the backend subpackages which own libs under this directory to also 
> > own the directory itself.
> 
> If you do so and remove just one subpackage, the whole directory will be
> removed.

This is not true. The directory will only be removed if _nobody_ owns it and if it's empty. - This is the desire you normally want for "plugins".

After getting more information on the subject, Dan and Ralf are correct and Dan's solution is the desired one.

Thanks a lot for the review and feedback!

Changes:
- the backends now explicity require opendbx of the same version
- filter out provides of backend subpackages
- use GPLv2+ as license for now because of the 2 GPLv2+ files (I've sent a mail to upstream about this)
- the backend subpackages each own the /usr/lib/opendbx directory

I have also sent a mail about the FSF addresses to upstream mailing list.

Updated Spec URL: http://mpreisle.fedorapeople.org/pkgs/opendbx/opendbx.spec
Updated SRPM URL:
http://mpreisle.fedorapeople.org/pkgs/opendbx/opendbx-1.4.5-3.fc15.src.rpm

Test build: http://koji.fedoraproject.org/koji/taskinfo?taskID=3424982

Taking it for review as I am a sponsor.

The %dir %{_libdir}/opendbx should be only in the base package and not duplicated in all of the backend subpackages.

I do not see anything else wrong.

(In reply to comment #10)
> Taking it for review as I am a sponsor.
> 
> The %dir %{_libdir}/opendbx should be only in the base package and not
> duplicated in all of the backend subpackages.

Why?

In cases, packages sharing directories depend upon each other in a strict hierarchic dependency, having a "base package" own the shared-directory and the "backends/plugins" not owning it is _one possible option_. 
The alternative is to let _all_, base and "backends/plugins" packages, which use this shared directory to let them own it.

It's up to the discretion of the packager to choose from these approaches.


In general, the second approach is much more flexible, general and superior approach. It is the only applicable approach when there is no strict hierarchy 

Classic example for such a case would be a plugin/backends system being used by several, independent frontends - Then sharing ownership of directories is mandatory.

Real world example for such a case in fedora is the perl-modules: Each perl-module package m must own all directories it owns, because there is no fixed, strict dependency between them.

Because not duplicating the directory ownership is preferable if the base package is required by the backends anyway.

(In reply to comment #12)
> Because not duplicating the directory ownership is preferable if the base
> package is required by the backends anyway.

... and when the package relationships change, your packages will be broken, because this approach lacks generality. 

It's a common issue,  many Red Hat packagers fail to understand because Red Hat has a long tradition in being trapped into this mistake.

There is not much to be changed in this concrete case as it is simple base/plugins subpackage relationship. I do not say anything about your Perl case as I do not know it and there it might make sense to do it the other way very much.

And, please, stop ad hominem attacks in the bugzilla comments.

(In reply to comment #14)
> There is not much to be changed in this concrete case as it is simple
> base/plugins subpackage relationship. I do not say anything about your Perl
> case as I do not know it and there it might make sense to do it the other way
> very much.
There are dozens of similar cases in Fedora ...

> And, please, stop ad hominem attacks in the bugzilla comments.
I don't see about any ad-hominem attack in my comments.

 Limitations of the the "base package" approach being present in all RH-based distros are well known, well understood and its origins (RH-tradition) also well understood. "base packages" offen technically suffice at one point in time, but they lack the flexibility and generality to cope with changes.

No, base packages might be "just a tradition" in case the base package is made so and otherwise it would not be needed. But here and in many many other cases the base package is just the simplest and straightest thing to do as where you would put the base library anyway.

And that's my last word here - bugzilla is not a forum for discussing packaging policies.

I believe that in this case the backends can never work without the base package, they don't even represent any value without it so the base package owning the directory is the preferred approach in my eyes. The chances of that situation changing are very very low.

Updated Spec URL: http://mpreisle.fedorapeople.org/pkgs/opendbx/opendbx.spec
Updated SRPM URL:
http://mpreisle.fedorapeople.org/pkgs/opendbx/opendbx-1.4.5-4.fc15.src.rpm

I have made the base package own the directory and the backends don't own it anymore.

Thanks Tomas for taking this package for a review!

I verified that the source tarball is identical to the upstream source tarball.

The package conforms to the Fedora naming and licensing guidelines.

rpmlint -v /var/lib/mock/fedora-rawhide-x86_64/result/*.rpm
opendbx-debuginfo.x86_64: I: checking
opendbx-debuginfo.x86_64: I: checking-url http://www.linuxnetworks.de/doc/index.php/OpenDBX (timeout 10 seconds)
opendbx-debuginfo.x86_64: E: incorrect-fsf-address /usr/src/debug/opendbx-1.4.5/utils/argmap.hpp
opendbx-debuginfo.x86_64: E: incorrect-fsf-address /usr/src/debug/opendbx-1.4.5/utils/argmap.cpp
Should be reported upstream, eventually.
opendbx-devel.x86_64: I: checking
opendbx-devel.x86_64: I: checking-url http://www.linuxnetworks.de/doc/index.php/OpenDBX (timeout 10 seconds)
opendbx-firebird.x86_64: I: checking
opendbx-firebird.x86_64: W: spelling-error Summary(en_US) backend -> backed, backbend, back end
opendbx-firebird.x86_64: W: spelling-error %description -l en_US odbx -> od bx, od-bx, Odis
opendbx-firebird.x86_64: W: spelling-error %description -l en_US backend -> backed, backbend, back end
Can be ignored.
opendbx-firebird.x86_64: I: checking-url http://www.linuxnetworks.de/doc/index.php/OpenDBX (timeout 10 seconds)
opendbx-firebird.x86_64: W: no-documentation
Well...
opendbx-firebird.x86_64: W: devel-file-in-non-devel-package /usr/lib64/opendbx/libfirebirdbackend.so
Not an error.
opendbx-mssql.x86_64: I: checking
opendbx-mssql.x86_64: W: spelling-error Summary(en_US) backend -> backed, backbend, back end
opendbx-mssql.x86_64: W: spelling-error %description -l en_US odbx -> od bx, od-bx, Odis
opendbx-mssql.x86_64: W: spelling-error %description -l en_US backend -> backed, backbend, back end
opendbx-mssql.x86_64: I: checking-url http://www.linuxnetworks.de/doc/index.php/OpenDBX (timeout 10 seconds)
opendbx-mssql.x86_64: W: no-documentation
opendbx-mssql.x86_64: W: devel-file-in-non-devel-package /usr/lib64/opendbx/libmssqlbackend.so
opendbx-mysql.x86_64: I: checking
opendbx-mysql.x86_64: W: spelling-error Summary(en_US) backend -> backed, backbend, back end
opendbx-mysql.x86_64: W: spelling-error %description -l en_US odbx -> od bx, od-bx, Odis
opendbx-mysql.x86_64: W: spelling-error %description -l en_US backend -> backed, backbend, back end
opendbx-mysql.x86_64: I: checking-url http://www.linuxnetworks.de/doc/index.php/OpenDBX (timeout 10 seconds)
opendbx-mysql.x86_64: W: no-documentation
opendbx-mysql.x86_64: W: devel-file-in-non-devel-package /usr/lib64/opendbx/libmysqlbackend.so
opendbx-postgresql.x86_64: I: checking
opendbx-postgresql.x86_64: W: spelling-error Summary(en_US) backend -> backed, backbend, back end
opendbx-postgresql.x86_64: W: spelling-error %description -l en_US odbx -> od bx, od-bx, Odis
opendbx-postgresql.x86_64: W: spelling-error %description -l en_US pgsql -> pasquil
opendbx-postgresql.x86_64: W: spelling-error %description -l en_US backend -> backed, backbend, back end
opendbx-postgresql.x86_64: I: checking-url http://www.linuxnetworks.de/doc/index.php/OpenDBX (timeout 10 seconds)
opendbx-postgresql.x86_64: W: no-documentation
opendbx-postgresql.x86_64: W: devel-file-in-non-devel-package /usr/lib64/opendbx/libpgsqlbackend.so
opendbx-sqlite.x86_64: I: checking
opendbx-sqlite.x86_64: W: spelling-error Summary(en_US) backend -> backed, backbend, back end
opendbx-sqlite.x86_64: W: spelling-error %description -l en_US odbx -> od bx, od-bx, Odis
opendbx-sqlite.x86_64: W: spelling-error %description -l en_US backend -> backed, backbend, back end
opendbx-sqlite.x86_64: I: checking-url http://www.linuxnetworks.de/doc/index.php/OpenDBX (timeout 10 seconds)
opendbx-sqlite.x86_64: W: no-documentation
opendbx-sqlite.x86_64: W: devel-file-in-non-devel-package /usr/lib64/opendbx/libsqlite3backend.so
opendbx-sqlite2.x86_64: I: checking
opendbx-sqlite2.x86_64: W: spelling-error Summary(en_US) backend -> backed, backbend, back end
opendbx-sqlite2.x86_64: W: spelling-error %description -l en_US odbx -> od bx, od-bx, Odis
opendbx-sqlite2.x86_64: W: spelling-error %description -l en_US sqlite -> sq lite, sq-lite, stylite
opendbx-sqlite2.x86_64: W: spelling-error %description -l en_US backend -> backed, backbend, back end
opendbx-sqlite2.x86_64: I: checking-url http://www.linuxnetworks.de/doc/index.php/OpenDBX (timeout 10 seconds)
opendbx-sqlite2.x86_64: W: no-documentation
opendbx-sqlite2.x86_64: W: devel-file-in-non-devel-package /usr/lib64/opendbx/libsqlitebackend.so
opendbx-sybase.x86_64: I: checking
opendbx-sybase.x86_64: W: spelling-error Summary(en_US) backend -> backed, backbend, back end
opendbx-sybase.x86_64: W: spelling-error %description -l en_US odbx -> od bx, od-bx, Odis
opendbx-sybase.x86_64: W: spelling-error %description -l en_US backend -> backed, backbend, back end
opendbx-sybase.x86_64: I: checking-url http://www.linuxnetworks.de/doc/index.php/OpenDBX (timeout 10 seconds)
opendbx-sybase.x86_64: W: no-documentation
opendbx-sybase.x86_64: W: devel-file-in-non-devel-package /usr/lib64/opendbx/libsybasebackend.so
opendbx-utils.x86_64: I: checking
opendbx-utils.x86_64: W: spelling-error %description -l en_US odbx -> od bx, od-bx, Odis
opendbx-utils.x86_64: W: spelling-error %description -l en_US sql -> sq, ql, sal
opendbx-utils.x86_64: I: checking-url http://www.linuxnetworks.de/doc/index.php/OpenDBX (timeout 10 seconds)
opendbx.src: I: checking
opendbx.src: I: checking-url http://www.linuxnetworks.de/doc/index.php/OpenDBX (timeout 10 seconds)
opendbx.src:162: W: macro-in-%changelog %{_libdir}
Please drop the % from the changelog entry.

opendbx.src: I: checking-url http://linuxnetworks.de/opendbx/download/opendbx-1.4.5.tar.gz (timeout 10 seconds)
opendbx.x86_64: I: checking
opendbx.x86_64: I: checking-url http://www.linuxnetworks.de/doc/index.php/OpenDBX (timeout 10 seconds)
12 packages and 0 specfiles checked; 2 errors, 40 warnings.

Package conforms to the packaging guidelines, please drop the % from the changelog entry so the macro is not expanded.

APPROVED

I have sponsored you for the packager group.

I have dropped % from the changelog.

New Package SCM Request
=======================
Package Name: opendbx
Short Description: Lightweight but extensible database access library written in C
Owners: mpreisle
Branches: f16 el6
InitialCC:

Git done (by process-git-requests).

opendbx-1.4.5-5.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/opendbx-1.4.5-5.fc16

opendbx-1.4.5-5.fc16 has been pushed to the Fedora 16 stable repository.