http://wiki.qt.io/Qbs → https://
http://download.qt.io/official_releases/ → https://

> LGPLv2 and LGPLv3, with exceptions

I think this should be "LGPLv2 with exceptions and LGPLv3 with exceptions" (following https://fedoraproject.org/wiki/Licensing:Main#Software_License_List).

> # qbs was previously packaged as part of qt-creator, using the qt-creator version
> Obsoletes:      %{name} < 0:4.4.0

Shouldn't this be "qt-creator < 0:4.4.0" instead?
Also, note that the new qt-creator package should have Obsoletes: %{name} < 0:4.4.0, so called self-obsoletes, so that both packages are installed during upgrade.

s/Examples for projects/Example projects/

https://fedoraproject.org/wiki/Packaging:Scriptlets#Shared_libraries are needed.

Looks good otherwise.

Thanks for the comments and sorry for the late reply, I was trying to get the tests working with upstream - still having some issues.

Uhm why obsoletes qt-creator? Qbs is currently a subpackage of qt-creator, it's that package that should be obsoleted, not the entire qt-creator. Or am I missing something?

Current version:
SPEC: https://smani.fedorapeople.org/review/qbs.spec
SRPM: https://smani.fedorapeople.org/review/qbs-1.8.1-2.fc27.src.rpm

dnf does not care which srpm a subpackage is built from. But there's no qbs package with a version < 0:4.4.0, so the Obsoletes line right now does nothing.

But there's a different consideration: when upgrading, users who had qt-creator-4.2.rpm installed, should get *both* qt-creator-4.4.rpm and qbs.rpm. For that to happen, you make both packages obsolete the old name:

qt-creator: Obsoletes: %{name} < 0:4.4.0
qbs: Obsoletes: qt-creator < 0:4.4.0

Then when upgrading, dnf should install both subpackages. At least that's what happened at some time with yum and should happen with dnf. There are bugs open for some corner cases, it seems it doesn't always work, but doing this better than nothing: https://bugzilla.redhat.com/show_bug.cgi?id=1261034, "Scenario C".

> http://wiki.qt.io/Qbs → https://
> http://download.qt.io/official_releases/ → https://
Still there.

Package is APPROVED. Please fix the http URL when uploading. I think you should add the Obsoletes, push qt-creator-4.4 and qbs in a single bodhi update, and test if the upgrades work as expected.

The qbs subpackage is only f27+ with qt-creator-4.3.x, see [1]. This actually makes it tricky now that I think of it though, since Obsoleting qbs will work fine for current rawhide users, but users updating from f26 to f27 will indeed hit the scenario you describe. So I think I actually have to obsolete both qt-creator and qbs?

[1] https://koji.fedoraproject.org/koji/packageinfo?packageID=8039

OK, I wasn't aware of the subpackage in rawhide. But this doesn't really change anything: dnf doesn't care from what srpm a binary subpackage originates. So when you just move the subpackage from qt-creator to a new srpm, nothing needs to be done (and the Obsoletes is not useful but harmless). So yeah, I still think you need to add the two Obsoletes as described for F26→F27+ upgrades.

Okay, thanks for the review!

Uhm,

 Problem 1: both package qbs-1:1.9.0-0.1.gita2fd0f3.fc27.x86_64 and qt-creator-4.4.0-0.1.beta1.fc27.x86_64 obsolete qt-creator < 4.4.0
  - cannot install the best update candidate for package qbs-4.3.1-2.fc27.x86_64

Would that be one of the issues in #1261034?

What was the command that gave this error?

Just a plain

# dnf update

By the way, since there is a DSO dependency 

/usr/lib64/qtcreator/plugins/libQbsProjectManager.so -> libqbscore.so.1.8

it is already taken care of that updating qt-creator will also install the new qbs. So actually I think no Obsoletes are even necessary.

Package request has been approved: https://admin.fedoraproject.org/pkgdb/package/rpms/qbs