Bug 626122 (libqmf)

*** Bug 617610 has been marked as a duplicate of this bug. ***

I'm not sure what to suggest as an alternative, but IMHO "libqmf" is a rather misleading/confusing name for this package.

 - This proposed 'libqmf' doesn't appear to contain any  libqmf.so
 - Fedora already has a 'qmf' RPM that does provide a libqmf.so

(In reply to comment #2)
> I'm not sure what to suggest as an alternative, but IMHO "libqmf" is a rather
> misleading/confusing name for this package.
>  - This proposed 'libqmf' doesn't appear to contain any  libqmf.so
>  - Fedora already has a 'qmf' RPM that does provide a libqmf.so

This is a git snapshot actually, no formal tarball available currently. I also doubt the pkgname, I sent a private mail to a maintainer of qmf, but haven't got any response yet. 

I use libqmf as the pkgname mainly because the package install api docs to %{_docdir}/libqmf-doc.

That's good, if they've not done any formal upstream release yet, then its definitely worth encouraging them to change the naming to avoid this obvious namespace clash.

(In reply to comment #4)
> That's good, if they've not done any formal upstream release yet, then its
> definitely worth encouraging them to change the naming to avoid this obvious
> namespace clash.

I think we have two choice:

1.Rename fedora qmf rpm to libqmf, then use qmf for this package(actually all other distributions use qmf for this package)

2. Keep fedora qmf rpm, then persuade Nokia to name this package as libqmf.

Currently, I can't other reasonable name for this package. FYI, upstream tend to call this package as qmf.

See http://qt.gitorious.org/qt-labs/messagingframework/blobs/master/README

We could call it qt-qmf or something.

What is the status of this package?

We're trying to negotiate the qmf namespace clash with qpid-cpp maintainers (that package currently produces subpkgs named qmf and qmf-devel).

(In reply to comment #8)
> We're trying to negotiate the qmf namespace clash with qpid-cpp maintainers
> (that package currently produces subpkgs named qmf and qmf-devel).

https://bugzilla.redhat.com/show_bug.cgi?id=661736

I guess I'll mark this as not being ready; please clear the whiteboard if the issue is resolved and this review can progress.

Let's just go with qt-qmf here, and not block indefinitely waiting on bug #661736

ok?

Just took a peek at the latest .spec here, and noticed
BuildRequires: libacccounts-qt-devel
where's this come from?

(In reply to comment #11)
> Let's just go with qt-qmf here, and not block indefinitely waiting on bug
> #661736
> 
> ok?

ok for me

(In reply to comment #12)
> Just took a peek at the latest .spec here, and noticed
> BuildRequires: libacccounts-qt-devel
> where's this come from?

https://bugzilla.redhat.com/show_bug.cgi?id=617592

seems to be built only for rawhide - http://koji.fedoraproject.org/koji/packageinfo?packageID=10789

(In reply to comment #11)
> Let's just go with qt-qmf here, and not block indefinitely waiting on bug
> #661736
> 
> ok?

OK for me also, maybe we can try to persuade upstream to rename this package to qt-qmf as well. 

Mailing list: http://lists.qt.nokia.com/mailman/listinfo/qt-qmf

[Upstream QMF developer here]

Just to add to the confusion:

There's two forks of QMF:
* http://qt.gitorious.org/qt-labs/messagingframework (What I call Qt-QMF)
* http://meego.gitorious.org/meego-middleware/messagingframework (What I call Meego-QMF)


Meego-QMF is rebased on a particular version commit of Qt-QMF (generally the weekly tags, but w/e suits their schedule) along with their set of commits (That adds stuff like libaccounts and tracker integration).

Going forward, I'd like to see this consolidated into a single library -- but for the time being that's not practical. 

But since you're packaging Meego-QMF, which is fine -- but calling it Qt-QMF would only add to the confusion. So maybe meego-qmf is a better name?

Regards,
Eric

(In reply to comment #16)
> [Upstream QMF developer here]
> 
> Just to add to the confusion:
> 
> There's two forks of QMF:
> * http://qt.gitorious.org/qt-labs/messagingframework (What I call Qt-QMF)
> * http://meego.gitorious.org/meego-middleware/messagingframework (What I call
> Meego-QMF)
> 
> 
> Meego-QMF is rebased on a particular version commit of Qt-QMF (generally the
> weekly tags, but w/e suits their schedule) along with their set of commits
> (That adds stuff like libaccounts and tracker integration).
> 
> Going forward, I'd like to see this consolidated into a single library -- but
> for the time being that's not practical. 
> 
> But since you're packaging Meego-QMF, which is fine -- but calling it Qt-QMF
> would only add to the confusion. So maybe meego-qmf is a better name?
> 
> Regards,
> Eric

Hi Eric!
Thanks for clarification. So meego-qmf should be compatible with qt-qmf? If so, we can ship meego-qmf as it adds some stuff and we can't have two nearly exactly same conflicting libraries. The question here is - rename it to meego-qt and after it's consolidated to one library move to qt-qmf? It's maybe even a little bit more confusing :(

Guys, what do you thing? QMF is an optional dep now for a few packages, so we should have it packaged...

Chen, are you still around and interested in this package review? Otherwise I can take care about it.

Looks like we'll be needing this sooner rather than later, as it's need by PyQtMobility which I'm working on packaging now.

I'll get to work on a newer build based on:
http://repo.meego.com/MeeGo/builds/trunk/latest/repos/oss/source/qmf-1.0.7~2011w13-1.51.src.rpm

anyone feel free to chime in and/or help, if you've got anything to add.

Hrm, that rpm uses qt-qmf it seems:
* Fri Mar 25 2011 Fathi Boudra <fathi.boudra> - 1.0.7~2011w11
- Update to 1.0.7~2011w11 and switch to upstream QMF
- Update URL

with
URL:        http://qt.gitorious.org/qt-labs/messagingframework

Now I'm confused on which one we should use. :(   oh well, I'll continue work on sync'ing with the srp rom repo.meego.com, and we'll go from there.

Well, so much for that qmf-1.0 doesn't seem to satisfy build requirements for either qt-mobility-1.2.x or PYQtMobility, trying a git snapshot of 
http://meego.gitorious.org/meego-middleware/messagingframework
now.

and, seems meego-qmf doesn't build, seemingly because fedora's libaccounts-qt-0.31-4.fc15.x86_64 is too old. :(

Pardon one minor rant, lack of qt/meego upstream releases or clear (versioned!) dependencies make resolving this more that a little frustrating. :(

(sorry for the multiple posts) in case it's useful for anyone,
http://rdieter.fedorapeople.org/rpms/qmf/
currently includes
qt-qmf-1.0.7-1.1011w13.fc15.src.rpm
my attempt at making an updated qmf-1.0.x rpm per comment #19

marking dead, reporter hasn't responded for quite awhile.