Spec URL: http://miroslav.suchy.cz/mzazrivec/dbxml.spec SRPM URL: http://miroslav.suchy.cz/mzazrivec/dbxml-2.3.10-5.fc7.src.rpm Description: Oracle Berkeley DB XML is an open source, embeddable XML database with XQuery-based access to documents stored in containers and indexed based on their content. Oracle Berkeley DB XML is built on top of Oracle Berkeley DB and inherits its rich features and attributes. Like Oracle Berkeley DB, it runs in process with the application with no need for human administration. Oracle Berkeley DB XML adds a document parser, XML indexer and XQuery engine on top of Oracle Berkeley DB to enable the fastest, most efficient retrieval of data.
Well, I just tried to rebuild this package but it failed. http://koji.fedoraproject.org/koji/taskinfo?taskID=217593 Note: you can try to rebuild your arbitrary srpm on koji by ---------------------------------------------------------------- koji build --scratch <target> <srpm_you_want_to_try> ---------------------------------------------------------------- Currently <target> can be dist-f9, dist-f8-updates-candidate or dist-fc7-updates-candidate.
By the way, would you make build.log more verbose? The build log output like: -------------------------------------------------------- (C++) Base64.o (C++) BinFileInputStream.o (C++) BinInputStream.o (C++) BinMemInputStream.o (C++) BitSet.o (C++) DefaultPanicHandler.o -------------------------------------------------------- isn't useful. We want to check if fedora specific compilation flags are correctly used, for example.
The build failure was caused by new version of Berkeley DB4 used in F8, the original dbxml package from Oracle relies on db4 version 4.3, 4.4 or 4.5. I created few patches that should make dbxml work with F8 and the new db4 API, removed that silent make build thing and merged 4 new upstream patches from Oracle. * New version: http://www.fi.muni.cz/~xzazriv/dbxml/ * dist-fc7-updates-candidate build: http://koji.fedoraproject.org/koji/taskinfo?taskID=219013 * dist-f8-updates-candidate build: http://koji.fedoraproject.org/koji/taskinfo?taskID=219018 * dist-f9 build: http://koji.fedoraproject.org/koji/taskinfo?taskID=219019
Well, I tried to check your srpm, however after a quick glance I found that this package uses xqilla library (I don't know at all), which has another URL and the latest seem 1.1.0. So please - split xqilla from this package and submit a new review request for xqilla - and make dbxml depend on external xqilla package.
Oh well, the whole compilation of dbxml is kinda icky. dbxml is basically a c++ library that depends on following libraries: * berkeley db4 (already in Fedora) * xerces-c (already in Fedora) * xqilla (we don't have it in Fedora) You also need specific version of xerces-c (2.7) and xqilla (1.0.1) for this version of dbxml to work properly (according to Oracle, different versions of these libraries may work, but it's not officially supported). dbxml source tarbal shipped by Oracle contains sources for all these libraries. Officially supported build procedure builds all of these libraries, creates its own directory structure and makes the libraries point to each other via rpath (this way dbxml uses its own libdb4, libxerces-c and libxqilla, which do not conflict with the versions you already may have in the system). The build procedure you can see in the spec file I provided basically removes things not compliant with fedora packaging guidelines (rpath, libtool archives, file hierarchy standard, etc.) and more importantly it relies on libdb4 and libxerces-c that's currently present in the system. We don't have XQilla in Fedora yet and we could certainly take the latest upstream version of XQilla and package it separately, but that would not help because: 1) The dbxml library relies on that particular version of xqilla. Oracle currently works on new version of dbxml that should use xqilla ver. 1.1.0, but that still a long shot. 2) To compile xqilla from sources, you need sources of xerces-c (not just the compiled libraries, you need sources of xerces-c too). That means that any source rpm for xqilla would have to contain sources of xerces-c too. I'd say the questions we need to answer here are: - is it acceptable for xqilla to be built from dbxml source rpm? - is it acceptable for xqilla source rpm to contain sources of xerces-c and use them during the build? If the answer to either of these two questions is no, I suggest this bz needs to be closed.
Well, (In reply to comment #5) > I'd say the questions we need to answer here are: > - is it acceptable for xqilla to be built from dbxml source rpm? This is usually unacceptable - It is always recommended that building libraries from tarballs provided from direct upstream, not from tarballs provided from other projects, because it makes maintainance procedure more visible - For this package this is more problematic because someone wants to package lastest xquilla and import it to Fedora, which will make conflict with your package. So you should rename xquilla 1.0.1 to xquilla101, for example (like libpng10), rename library name to avoid conflict from xquilla 1.1.0 and submit a seperate review request for xquilla 1.0.1. > - is it acceptable for xqilla source rpm to contain sources of xerces-c and use > them during the build? This is acceptable (IMO).
I created separate xqilla101 review request [1] and made the updated version of dbxml [2] depend on it. Hope that works! :-) [1] https://bugzilla.redhat.com/show_bug.cgi?id=376541 [2] http://www.fi.muni.cz/~xzazriv/dbxml/
Okay, would you update your srpm to use xqilla10?
I uploaded the updated spec file and source rpm [1], but I'm sure there's going to be the same problem with xqilla license here again -- source rpm contains sources for xqilla with the old mapm library license (same problem as in https://bugzilla.redhat.com/show_bug.cgi?id=376541#c9). I could probably split the sources of the dbxml library from the source tarball and put it somewhere on the internet (sf.net for example) -- that way I'd solve the problem with xqilla, I would crop the size of the source rpm to ~33% of it's original size (no sources for db4, xerces-c and xqilla) and I could incorporate some of the patches I had created. It wouldn't be a violation of the dbxml license, but it would be a project fork. Another solution would be asking Oracle for help -- either have them include the new mapm license and repack the source tarball, or have them split sources of dbxml library from the original tarball and put it on their web (IMO very unlikely to happen). Any suggestions from Fedora authorities? [1] http://www.fi.muni.cz/~xzazriv/dbxml
Cutting legally-problematic parts from original tarball and repackaging it is _not_ seldom done on Fedora. You can refer to wine spec, for example. http://cvs.fedoraproject.org/viewcvs/*checkout*/devel/wine/wine.spec and for ds9: http://cvs.fedoraproject.org/viewcvs/*checkout*/devel/ds9/ds9.spec
I removed all the irrelevant and problematic stuff from source tarball and repacked it. Thanks for the advice! New spec and source rpm can be found at: http://www.fi.muni.cz/~xzazriv/dbxml
Created attachment 289882 [details] mock build of 2.3.10-9 on i386 Well, currently as xqilla10 is not built on koji, I cannot check your package by koji scratch build. I just tried to mockbuild 2.3.10-9 on i386 but it failed as attached. By the way, would you write a direct link to your srpm so that I can directly download your srpm from it?
koji build result is here. http://koji.fedoraproject.org/koji/taskinfo?taskID=300556
New version: * http://www.fi.muni.cz/~xzazriv/dbxml/dbxml-2.3.10-9.fc8.src.rpm * http://www.fi.muni.cz/~xzazriv/dbxml/dbxml.spec dist-f9 build: * http://koji.fedoraproject.org/koji/taskinfo?taskID=318623
Milan, would you read or comment on the following thread? https://www.redhat.com/archives/fedora-packaging/2008-January/msg00002.html
I decided to remove perl bindings from the package and make it a new package: * https://bugzilla.redhat.com/show_bug.cgi?id=427373 New spec file and srpm: * http://www.fi.muni.cz/~xzazriv/dbxml/dbxml.spec * http://www.fi.muni.cz/~xzazriv/dbxml/dbxml-2.3.10-9.fc8.src.rpm Koji builds: * http://koji.fedoraproject.org/koji/taskinfo?taskID=322074 * http://koji.fedoraproject.org/koji/taskinfo?taskID=322092 * http://koji.fedoraproject.org/koji/taskinfo?taskID=322091
Almost okay. For 2.3.10-9: * EVR specific Requires between subpackages - Usually the dependency between subpackages must be EVR (Epoch-Version-Release) specific, not just Version. i.e. dbxml-utils must have "Requires: %{name} = %{version}-%{release}", for example. * Parallel make - Support parallel make if possible, otherwise please comment about not supporting parallel make. * Timestamps - Please try to keep timestamps on installed files when possible. * Please use "-p" option when using "cp" or "install" commands * Defattr - We now recommend %defattr(-,root,root,-) * Undefined non-weak symbol - "$ rpmlint dbxml" returns lots of undefined non-weak symbols ! Note rpmlint can be used for installed rpm. You can also check this by $ ldd -r /usr/lib/libdbxml-2.3.so (on i386) For this package this cannot be ignored because this package provides -devel subpackage and these symbols causes linkage failure. Perhaps libdbxml-2.3.so must be linked agaist some more libraries.
Source rpm + spec file: * http://www.fi.muni.cz/~xzazriv/dbxml/dbxml-2.3.10-9.fc9.src.rpm * http://www.fi.muni.cz/~xzazriv/dbxml/dbxml.spec Scratch builds: * http://koji.fedoraproject.org/koji/taskinfo?taskID=328170 * http://koji.fedoraproject.org/koji/taskinfo?taskID=328175 * http://koji.fedoraproject.org/koji/taskinfo?taskID=328180
Well, from next time please change the release number of srpm every time you modify your spec file to avoid confusion...
Okay. ---------------------------------------------------------- This package (dbxml) is APPROVED by me ----------------------------------------------------------
New Package CVS Request ======================= Package Name: dbxml Short Description: An embeddable XML database Owners: mzazrive Branches: F-7 F-8 InitialCC: Cvsextras Commits: yes
cvs done.
Closing as this is on devel repo and request on bodhi is already done.