Bug 250093 - Review Request: dbxml - An embeddable XML database
Review Request: dbxml - An embeddable XML database
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Mamoru TASAKA
Fedora Extras Quality Assurance
:
Depends On: 376541
Blocks: 427373
  Show dependency treegraph
 
Reported: 2007-07-30 10:04 EDT by Milan Zazrivec
Modified: 2008-01-08 08:59 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-01-08 08:59:59 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
mtasaka: fedora‑review+
kevin: fedora‑cvs+


Attachments (Terms of Use)
mock build of 2.3.10-9 on i386 (923.03 KB, text/plain)
2007-12-18 07:00 EST, Mamoru TASAKA
no flags Details

  None (edit)
Description Milan Zazrivec 2007-07-30 10:04:34 EDT
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.
Comment 1 Mamoru TASAKA 2007-10-28 11:39:11 EDT
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.
Comment 2 Mamoru TASAKA 2007-10-28 11:41:21 EDT
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.
Comment 3 Milan Zazrivec 2007-10-29 15:50:59 EDT
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
Comment 4 Mamoru TASAKA 2007-10-30 11:11:42 EDT
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.
Comment 5 Milan Zazrivec 2007-10-30 13:43:10 EDT
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.
Comment 6 Mamoru TASAKA 2007-10-31 12:10:02 EDT
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).

Comment 7 Milan Zazrivec 2007-11-11 16:42:54 EST
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/
Comment 8 Mamoru TASAKA 2007-12-17 12:32:23 EST
Okay, would you update your srpm to use xqilla10?
Comment 9 Milan Zazrivec 2007-12-17 13:57:54 EST
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
Comment 10 Mamoru TASAKA 2007-12-17 20:34:56 EST
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
Comment 11 Milan Zazrivec 2007-12-18 05:30:31 EST
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
Comment 12 Mamoru TASAKA 2007-12-18 07:00:57 EST
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?
Comment 13 Mamoru TASAKA 2007-12-19 08:04:26 EST
koji build result is here.
http://koji.fedoraproject.org/koji/taskinfo?taskID=300556
Comment 15 Mamoru TASAKA 2008-01-02 10:19:52 EST
Milan, would you read or comment on the following thread?

https://www.redhat.com/archives/fedora-packaging/2008-January/msg00002.html
Comment 17 Mamoru TASAKA 2008-01-05 11:04:05 EST
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.
Comment 19 Mamoru TASAKA 2008-01-06 09:28:54 EST
Well, from next time please change the release number of srpm every
time you modify your spec file to avoid confusion...
Comment 20 Mamoru TASAKA 2008-01-06 09:44:51 EST
Okay.

----------------------------------------------------------
   This package (dbxml) is APPROVED by me
----------------------------------------------------------
Comment 21 Milan Zazrivec 2008-01-06 12:02:08 EST
New Package CVS Request
=======================
Package Name: dbxml
Short Description: An embeddable XML database
Owners: mzazrive
Branches: F-7 F-8
InitialCC:
Cvsextras Commits: yes
Comment 22 Kevin Fenzi 2008-01-06 12:32:36 EST
cvs done.
Comment 23 Mamoru TASAKA 2008-01-08 08:59:59 EST
Closing as this is on devel repo and request on bodhi is already done.

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