Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 226515 - Merge Review: unixODBC
Summary: Merge Review: unixODBC
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Peter Lemenkov
QA Contact: Fedora Package Reviews List
Depends On: 203641
TreeView+ depends on / blocked
Reported: 2007-01-31 21:13 UTC by Nobody's working on this, feel free to take it
Modified: 2009-06-09 11:32 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-06-09 11:31:19 UTC
lemenkov: fedora-review+

Attachments (Terms of Use)

Description Nobody's working on this, feel free to take it 2007-01-31 21:13:21 UTC
Fedora Merge Review: unixODBC
Initial Owner:

Comment 1 Patrice Dumas 2007-02-01 16:33:28 UTC
I think it is time to reassess where dlopened objects should be.
In my opinion the best thing is to have them in a %_libdir subdir
and to change the default config file accordingly.

The issue of retro compatibility is important too, so I think that 
for a given number of fedora releases there could be symlinks pointing 
from the old location to the new location, and a README.fedora 
file could be added stating that in a given number of versions the 
dlopened objects will be removed from %_libdir.

Comment 2 Peter Lemenkov 2008-08-29 18:12:58 UTC
I'll try to review it.

Comment 3 Peter Lemenkov 2008-12-10 20:06:24 UTC
Ok, finally found free time to review it. 

BTW, Tom, are you planning to update (at least devel branch) to 2.2.14?

Comment 4 Tom Lane 2008-12-10 22:46:25 UTC
I would like to push 2.2.14 into rawhide, but the immediate problem is that upstream decided to remove the "text" driver, which leaves us with a functionality gap.  I haven't decided whether it's worth trying to get that driver packaged separately or not.  I have gotten bugs indicating that people have used it in the past ...

Comment 5 Peter Lemenkov 2009-04-21 14:27:06 UTC
Ok, since 2.2.14. is in Rawhide - here is my review request:

- rpmlint  is not silent:

We may ignore messages, regarding non-versioned so-files in %{_libdir} and zero-length /etc/odbc.ini, however other messages needs fixing. 

* You must convert ChangeLof from iso8859-1 in %prep
* You must remove executable permisson from files, mentioned my rpmlint.

+/- The package is named according to the Package Naming Guidelines. Unfortunately (perhaps, due to historical reasons) GUI module for unixODBC is named as unixODBC-kde, although it has almost nothing to do with KDE (purely Qt-based - the only link between them is DataManager(II) applications, used by KDE afaik). To be honest, I'd like this package to be renamed to something like unixODBC-gui, but the unixODBC package has very long history and even this small change may be relatively painless.

+ The spec file name matches the base package %{name}, in the format %{name}.spec unless your package has an exemption.
+ The package meets the Packaging Guidelines.
+ The package is licensed with a Fedora approved license and meets the Licensing Guidelines.
+ The License field in the package spec file matches the actual license.
+ The file, containing the text of the license(s) for the package, is included in %doc.
+ The spec file is written in American English. Although I'm not a native english speaker and, therefore, this requirement of Fedora Review Giiudelines always confusing me :).
+ The spec file for the package is be legible.
+ The sources used to build the package are matching the upstream source:

[petro@Sulaco SOURCES]$ md5sum unixODBC-2.2.14.tar.gz*
f47c2efb28618ecf5f33319140a7acd0  unixODBC-2.2.14.tar.gz
f47c2efb28618ecf5f33319140a7acd0  unixODBC-2.2.14.tar.gz_from_srpm
[petro@Sulaco SOURCES]$

+ The package successfully compiles and builds into binary rpms on at least one primary architecture.

+ All build dependencies are listed in BuildRequires.
+ Every binary RPM package (or subpackage) which stores shared library files (not just symlinks) in any of the dynamic linker's default paths, calling ldconfig in %post and %postun.
+ A package owns all directories that it creates.
+ The package does not list any file more than once in the spec file's %files listings.
+/- Permissions on files must be set properly, except those, noted above (easyfix).
+ The package has a %clean section, which contains rm -rf %{buildroot} (or $RPM_BUILD_ROOT).
+ The package consistently uses macros.
+ The package contains code, or permissable content.
+ The package does not contain etremely large chunks of documentation.
+ Anything, the package includes as %doc, does not affect the runtime of the application.
+ C header files are in a -devel package.
+ No static libraries.
+ The package does not contains pkgconfig(.pc) files.
+ The devel sub-package requires the base package using a fully versioned dependency: Requires: %{name} = %{version}-%{release}.
+ The package does NOT contain any .la libtool archives.

- The sub-package containing GUI applications does include a %{name}.desktop file. Unfortunately, it does NOT properly installed with desktop-file-install in the %install section.

+ The package does not own files or directories already owned by other packages.
+ At the beginning of %install, the package runs rm -rf %{buildroot} (or $RPM_BUILD_ROOT). 
+ All filenames in the package must be valid UTF-8.

So, please, 

* use proper installation procedure of desktop-files ( )
* Suppress rpmlint messages

Comment 6 Peter Lemenkov 2009-06-09 11:31:19 UTC
All changes merged into F-11 and devel branches, so I think we may close this ticket.

Comment 7 Peter Lemenkov 2009-06-09 11:32:03 UTC
Koji scratch build

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