Found a small issue in the %description of devel. It is a bit truncated :)

Will fix that in the next upload.

Brief look at the spec file and automated Plague/Mock build attempt for dist-f19:


> Summary:    Qt Build Suite

This is the name of the software and not a helpful summary:
https://fedoraproject.org/wiki/Examples_of_good_package_summaries


> License:    LGPLv2 with exceptions

How much has this been reviewed already?

https://fedoraproject.org/wiki/Licensing:Main#Good_Licenses

  | Please be sure that any exceptions are approved by emailing them
  | to legal.org first. 

It's also less than ideal to include the license terms only in the optional -doc package instead of the base package.
https://fedoraproject.org/wiki/Packaging:LicensingGuidelines#Subpackage_Licensing


* https://fedoraproject.org/wiki/Packaging:Guidelines#Requiring_Base_Package


* https://fedoraproject.org/wiki/Packaging:Guidelines#File_and_Directory_Ownership
  https://fedoraproject.org/wiki/Packaging:UnownedDirectories


> -rw-rw-r--. 1 root root  653400 Jun 29 13:59 qbs-1.0.1-1.fc19.x86_64.rpm
> -rw-rw-r--. 1 root root   21044 Jun 29 13:59 qbs-cpp-1.0.1-1.fc19.x86_64.rpm
> -rw-rw-r--. 1 root root 5718148 Jun 29 13:59 qbs-debuginfo-1.0.1-1.fc19.x86_64.rpm
> -rw-rw-r--. 1 root root   11548 Jun 29 13:59 qbs-devel-1.0.1-1.fc19.x86_64.rpm
> -rw-rw-r--. 1 root root   12700 Jun 29 13:59 qbs-doc-1.0.1-1.fc19.x86_64.rpm
> -rw-rw-r--. 1 root root   62700 Jun 29 13:59 qbs-qt-1.0.1-1.fc19.x86_64.rpm

A lot of fragmentation and tiny subpackages for no gain, IMO. Notice how the base package contains other parts for C++ and Qt support (e.g. plugins). This is somewhat half-hearted and certainly could be improved.

The -cpp and -qt subpackages don't even add any dependencies.

The -doc subpackage doesn't include the HTML documentation it advertizes.

$ rpmls -p qbs-doc-1.0.1-1.fc19.x86_64.rpm 
drwxr-xr-x  /usr/share/doc/qbs
drwxr-xr-x  /usr/share/doc/qbs-doc-1.0.1
-rw-r--r--  /usr/share/doc/qbs-doc-1.0.1/LGPL_EXCEPTION.txt
-rw-r--r--  /usr/share/doc/qbs-doc-1.0.1/LICENSE.LGPL
-rw-r--r--  /usr/share/doc/qbs-doc-1.0.1/README

Hi,

> This is the name of the software and not a helpful summary

From the link you gave me:
[...]
For some
packages it may be helpful to expand the package name that is an
acronym, e.g. for the package "gimp", the summary could be "GNU Image
Manipulation Program".
[...]

This looks exactly like what I am doing. I also have no idea how i could summarize this package better than this. (But I am open for suggestions).

> How much has this been reviewed already?

Sorry I am a rather new and not very active packager. I did not read a lot of reviews (and never did one myself). I only looked at other packages (qt-creator in this case) and copied that over from there.

I will look into the process and fix it.

> It's also less than ideal to include the license terms only in the optional -doc package instead of the base package.
Hm. I thought %doc would do exactly that. I did not know that it only puts it into the -doc package (I also was unable to find any documentation about this right now :/). Can i somehow do %doc for a specific subpackage? (the main package)?

> * https://fedoraproject.org/wiki/Packaging:Guidelines#Requiring_Base_Package

What do you mean with this?
Shall I require the base package from the doc subpackage too?

> * https://fedoraproject.org/wiki/Packaging:Guidelines#File_and_Directory_Ownership
>  https://fedoraproject.org/wiki/Packaging:UnownedDirectories
Hm. Could you give some info on this? What do I do wrong?

Should the main package maybe own %{_datadir}/%{name}/modules/?

Would be good if you could give some context.

> A lot of fragmentation and tiny subpackages for no gain, IMO. Notice how the base package contains other parts for C++ and Qt support (e.g. plugins). This is somewhat half-hearted and certainly could be improved.
Eeh. Somehow did not notice that. The plugins of course should be owned by the subpackages.

> The -cpp and -qt subpackages don't even add any dependencies.
Sorry I do not understand. What kind of depedencies do you expect? They depend on the main package. And that should be the only thing they need to depend on if i see it right?

> The -doc subpackage doesn't include the HTML documentation it advertizes.
Right. I first worked with a different patch applied for this. That patch got merged into upstream then. However they apparently do not install the docs this way anymore.

Another thing i just realized. doc should probably be noarch, right?

Thanks a lot for your first glance and have a nice remaining weekend,
Erik

> From the link you gave me:

Examples, not mandatory, some of them are debatable, too. ;)


> For some packages it may be helpful to expand the package name
> that is an acronym, e.g. for the package "gimp", the summary
> could be "GNU Image Manipulation Program".

"Image manipulation program" would be sufficient. The description could expand on the "GNU" part in the name and whether/why it matters.


> This looks exactly like what I am doing.

I didn't say the current %summary would be a blocker. But could it be improved? That might be difficult. The program is not specific to "Qt", so why mention Qt in the summary at all?

What about these two?

  Next-generation build system for projects
  Build suite from the Qt Project
  Simplify the build process for developing projects across multiple platforms

Roughly copied from: http://doc-snapshot.qt-project.org/qbs/


> Hm. I thought %doc would do exactly that. I did not know that it
> only puts it into the -doc package (I also was unable to find any
> documentation about this right now :/).

The %doc macro is specific to the %files section you use it within, and what it does depends on the type of file path you apply it to:
http://www.rpm.org/max-rpm/s1-rpm-inside-files-list-directives.html


> > * https://fedoraproject.org/wiki/Packaging:Guidelines#Requiring_Base_Package
>
> What do you mean with this?

You currently do

  Requires:   %{name} = %{version}-%{release}

in the subpackages, but the guidelines suggest you do

  Requires: %{name}%{?_isa} = %{version}-%{release}

to make those dependencies arch-specific.


> Shall I require the base package from the doc subpackage too?

No. Separate documentation -doc packages typically don't require the base package. It should be possible to install documentation without having to install a program and all its dependencies.


> > * https://fedoraproject.org/wiki/Packaging:Guidelines#File_and_Directory_Ownership
> >  https://fedoraproject.org/wiki/Packaging:UnownedDirectories
> 
> Hm. Could you give some info on this? What do I do wrong?
>
> Should the main package maybe own %{_datadir}/%{name}/modules/?

You're on the right track. :-)  There are several "unowned" directories in your package. They are easy to spot in the spec file or when listing the package contents with e.g. "rpmls -p …" or "rpm -qlp …".


> > The -cpp and -qt subpackages don't even add any dependencies.
>
> Sorry I do not understand.

Why do you put those files into separate (= optional) packages at all? Why not include those files in the main "qbs" package? What is the benefit of splitting them off?


> What kind of depedencies do you expect?

Well, I don't understand why you split off those files. A query such as

  rpm -qpR qbs-cpp-1.0.1-1.fc19.x86_64.rpm

currently does not list any requirement not already required by the base package.


> Another thing i just realized. doc should probably be noarch, right?

Good idea.

Ok I did those changes now:
- Tried to make the summary of the main package better
- Splitted the ui part in order to prevent depedency on ui libs for the core packages
- Fixed ownership of the plugins (they are now actually owned by their subpackages)
- Fixed ownership of some directories
- Moved %%doc to the main package
- Made the requirement of the base package arch-specific
- Fixed html doc installation
- Made the doc package noarch


I splitted the ui executable into a seperate package to prevent having QtGui in the main one.

So now only the cpp subpackage does not require any additional packages.

However i wonder whether this really makes sense... In the future there will come more modules for different languages. I think it would be more consistent to have all of those modules as subpackage instead of having some included and some not. But well I am open for suggestions here.

I also asked about the lgpl exception on the maillinglist (CC'd you).

I hope I caught all unowned directories (is there some kind of tool to help checking for this?).

Otherwise I think I fixed all the issues you mentioned.

Regards and thanks a lot for your comments,
Erik

Updated SPEC file: http://ablu.fedorapeople.org/qbs.spec
New SRPM file: http://ablu.fedorapeople.org/qbs-1.0.1-2.fc19.src.rpm

No further review, just these comments:

> I also asked about the lgpl exception on the maillinglist (CC'd you).

Thanks! It could be worthwhile to add a comment to the spec file about that, also pointing out that the license terms are the same than in "qt" and "qt-creator".


> I hope I caught all unowned directories (is there some kind of tool
> to help checking for this?).

Not that I know of. An experimental script I've published several years ago (dircheck-remote.py) has not been developed further after it had been used to report lots of unowned dirs. An improved tool would not only need to find unowned directories, but also attempt at suggesting which packages in the distribution ought to own the directories. Else packagers misinterpret the results and add directories to the wrong packages just to please the tool. In the past, so-called "multiple ownership of directories" has not been permitted.

Nowadays, the directory ownership guidelines are more lax. That means, in some cases you don't need to strictly require a separate package just to get complete directory ownership. You can include some directories in your own package to avoid a dependency (provided that you copy the correct permissions):
  https://fedoraproject.org/wiki/Packaging:Guidelines#The_directory_is_owned_by_a_package_which_is_not_required_for_your_package_to_function


Common sense, a good understanding of your own package inter-dependencies and package contents, knowledge of the guidelines and "filesystem" packages, and basic package queries with "rpmls -p" (or "rpm -qlvp") should be enough to spot missing dir entries. For example, with a first brief look such as

  $ rpmls -p qbs-1.0.1-1.fc19.x86_64.rpm|grep ^d
  drwxr-xr-x  /usr/lib64/qbs
  drwxr-xr-x  /usr/lib64/qbs/plugins
  drwxr-xr-x  /usr/share/qbs/imports
  drwxr-xr-x  /usr/share/qbs/imports/qbs
  drwxr-xr-x  /usr/share/qbs/imports/qbs/base
  drwxr-xr-x  /usr/share/qbs/imports/qbs/base/qmlapplicationviewer
  drwxr-xr-x  /usr/share/qbs/imports/qbs/fileinfo
  drwxr-xr-x  /usr/share/qbs/imports/qbs/probes
  drwxr-xr-x  /usr/share/qbs/modules/qbs

one can see that there is no 'd' entry for /usr/share/qbs. With a look at the %files section (any files with long paths there?) or a second query (without grep ^d) you can check all files in a package and determine whether any parent dirs are missing and belong into your package(s). Very often that's simple enough.

Of course, for huge packages which contain deep file trees, often you would include only the top dir path in the %files section and be done. If, on the contrary, you create many subpackages with complex inter-dependencies, directory ownership gets more complicated, too. Eventually you'll find that splitting of a shared -filesystem subpackage may be helpful.

Yeah.

Imagine when an end-user uninstall your package and find some directories left in /usr/share, it's ugly.

I took a look at 2 rev of yor spec, if you have license confusion, ask spot to review. He is good at such things.

And for the summary argument, I think you can take a look at archlinux's naming:

https://aur.archlinux.org/packages/qbs-git

As you can see, "The Qt Build Suite" is nice.

Last one, you'd better scratch a build on koji with your SRPM, maybe we can see if something wrong there.

> Thanks! It could be worthwhile to add a comment to the spec file about that, also pointing out that the license terms are the same than in "qt" and "qt-creator".

I added a comment to clarify that + added a link to the maillinglist reply.

> As you can see, "The Qt Build Suite" is nice.

Hm. I like the current name too. So I do not really mind about which one to take. But Michael Schwendt apparently prefers the current one :)

> Last one, you'd better scratch a build on koji with your SRPM, maybe we can see if something wrong there.

Ah. Sorry forgot this. Doing one atm.


Changes:
- Added comment to license section to clarify the situation with the exceptions
- Added missing share/qbs dir to the main package

Updated SPEC file: http://ablu.fedorapeople.org/qbs.spec
New SRPM file: http://ablu.fedorapeople.org/qbs-1.0.1-3.fc19.src.rpm
Koji build: http://koji.fedoraproject.org/koji/taskinfo?taskID=5578842


Thanks a lot for all your comments and have a nice weekend,
Erik

Issues:
=======
1. Header files in -devel subpackage. Quoted from rpmlint result:

qbs.i686: W: devel-file-in-non-devel-package /usr/share/qbs/imports/qbs/base/qmlapplicationviewer/qmlapplicationviewer_qt5.cpp
qbs.i686: W: devel-file-in-non-devel-package /usr/share/qbs/imports/qbs/base/qmlapplicationviewer/qmlapplicationviewer.h
qbs.i686: W: devel-file-in-non-devel-package /usr/bin/qbs-config
qbs.i686: W: devel-file-in-non-devel-package /usr/share/qbs/imports/qbs/base/qmlapplicationviewer/qmlapplicationviewer_qt4.cpp
qbs.i686: W: devel-file-in-non-devel-package /usr/share/qbs/imports/qbs/base/qmlapplicationviewer/qmlapplicationviewer_qt5.h
qbs.i686: W: devel-file-in-non-devel-package /usr/share/qbs/imports/qbs/base/qmlapplicationviewer/qmlapplicationviewer_qt4.h

  See: http://fedoraproject.org/wiki/Packaging/Guidelines#DevelPackages for solutions.

2. Unversioned so-files in private %_libdir subdirectory.

qbs-qt: /usr/lib/qbs/plugins/libqbs_qt_scanner.so
qbs-cpp: /usr/lib/qbs/plugins/libqbs_cpp_scanner.so

Verify they are not in ld path.

3. Checking Licenses found:
     "MIT/X11 (BSD like)", "Unknown or generated". 390 files have unknown

4. unused-direct-shlib-dependency rpmlint issue
qbs.i686: W: unused-direct-shlib-dependency /usr/lib/libqbscore.so.1.0.0 /lib/libQtTest.so.4
qbs.i686: W: unused-direct-shlib-dependency /usr/lib/libqbscore.so.1.0.0 /lib/libm.so.6

   See https://fedoraproject.org/wiki/Common_Rpmlint_issues#unused-direct-shlib-dependency for soltuion.

5. Some headers are in non-devel package:

qbs.i686: W: devel-file-in-non-devel-package /usr/share/qbs/imports/qbs/base/qmlapplicationviewer/qmlapplicationviewer_qt5.cpp
qbs.i686: W: devel-file-in-non-devel-package /usr/share/qbs/imports/qbs/base/qmlapplicationviewer/qmlapplicationviewer.h
qbs.i686: W: devel-file-in-non-devel-package /usr/bin/qbs-config
qbs.i686: W: devel-file-in-non-devel-package /usr/share/qbs/imports/qbs/base/qmlapplicationviewer/qmlapplicationviewer_qt4.cpp
qbs.i686: W: devel-file-in-non-devel-package /usr/share/qbs/imports/qbs/base/qmlapplicationviewer/qmlapplicationviewer_qt5.h
qbs.i686: W: devel-file-in-non-devel-package /usr/share/qbs/imports/qbs/base/qmlapplicationviewer/qmlapplicationviewer_qt4.h

Created attachment 769525 [details]
QBS License Check

Christopher, please slow down a bit. Verify output from fedora-review carefully.

(In reply to Michael Schwendt from comment #11)
> Christopher, please slow down a bit. Verify output from fedora-review
> carefully.

Please give me a hand if possible...

> 2. Unversioned so-files in private %_libdir subdirectory.
> …
> Verify they are not in ld path.

They are plug-ins in a path local to the application. The package does not adjust the run-time linker's search path, so explain your concerns. Be more verbose about what you think is wrong or could be wrong.


> 3. Checking Licenses found:
>      "MIT/X11 (BSD like)", "Unknown or generated". 390 files have unknown

What do you want the submitter to do here? A few files offer multiple alternative licenses including the LGPLv2 as the whole project applies.


> 5. Some headers are in non-devel package:

All the built qbs* packages are for "development", and those source files (data files in %_datadir even!) are needed at run-time and do not belong into the qbs-devel package either (see its %description).

> 1. Header files in -devel subpackage. Quoted from rpmlint result:

Those header / source files are required by the qbs-qt package. They allow you to simply define a QmlApplication {} with qbs without needing to bundle the qml viewer all the time (which is the current practise usually). Those files are added to your project if you need them. So those are no files that should go into a -devel package (i think).

> 2. Unversioned so-files in private %_libdir subdirectory.

Not sure what I did wrong here. Can you give me a link about a guideline which forbids this? Qt does a similar thing for its plugins or not?

> 3. Checking Licenses found:

Hm. No idea what you mean here. The code files all have the default qt header as far as i can see.

> 4. unused-direct-shlib-dependency rpmlint issue

How did you get this rpmlint output?

Well I will try to look into this issue. Though I am not sure if / how i can change this with qmake at the moment (help is welcome :))

> 5. [...]

See my reply to 1.


Regards,
Erik

> https://aur.archlinux.org/packages/qbs-git
> 
> As you can see, "The Qt Build Suite" is nice.

Well, good summaries sum up what the package contains. They don't just repeat the name of a program (or expand its acronym). Insiders already know what Qt is, what it stands for and that this "build suite" is not specific to building Qt itself. They will know how to find this or that this is likely named "qbs". Let's make summaries more helpful for everyone in displayed search results. A developer searching for a build system or build framework will be thankful.

As pointed out, the %summary would not be a blocker. It's just that we've come a long long way from many packages with poor summaries, so that's why I mention summaries that could be improved.

If there are strong feelings about it, consider a compromise similar to:

  Summary: The Qt Build Suite is a next-generation build system for projects

Also try:

  yum search build system |grep -i "build system"

They aren't bad examples (and the summary doesn't need to explain what Boost is or why there is "Ninja" in the package name):

  boost-build.noarch : Cross platform build system for C++ projects
  ninja-build.x86_64 : A small build system with a focus on speed
  ocaml-omake.x86_64 : Build system with automated dependency analysis
  php-pear-phing.noarch : A project build system based on Apache Ant
  remake.x86_64 : Build system that bridges the gap between make and redo

| waf.noarch : A Python-based build system

better: Build system written in Python

| gradle.noarch : Groovy based build system

better: Build system written in Groovy

Hm. I tried to remove the libm dependency by passing QMAKE_LFLAGS += "-Wl,-as-needed".

However this flags do not seem to apply (I do not see them in the build log.)

Anyone having an idea what i do wrong there (I do not have a lot of experience with qmake)?

However I was able to remove the QtTest link by removing it from the .pro file.

Regards,
Erik

I now fixed this.

- Prevent linking to unneeded libs

Updated SPEC file: http://ablu.fedorapeople.org/qbs.spec
New SRPM file: http://ablu.fedorapeople.org/qbs-1.0.1-4.fc19.src.rpm
koji build: http://koji.fedoraproject.org/koji/taskinfo?taskID=5594474

I contacted upstream regarding this QtTest linkage and they fixed it for the next release.

Regards,
Erik

Note: qt-creator was released 4 days ago and it ships qbs now since it supports opening and working with qbs project files. So the qt-creator qbs plugin will need to build against this qbs package once it makes it into the repos.

Regards,
Erik

New release, new package, new try:

- New upstream release 1.1.0
- Changed package to build with Qt 5
- Introduced new examples subpackage for the newly installed examples
- Made the qt module depend on the cpp one 
- Updated summary of -devel to point out that it is only required for native modules

Updated SPEC: http://ablu.fedorapeople.org/qbs.spec
New SRPM: http://ablu.fedorapeople.org/qbs-1.1.0-1.fc20.src.rpm
New koji build: http://koji.fedoraproject.org/koji/taskinfo?taskID=6145864

rpmlint:
qbs.src: W: spelling-error %description -l en_US qmake -> make, quake, q make
qbs.src: W: spelling-error %description -l en_US cmake -> cake, make, c make
qbs.x86_64: W: spelling-error %description -l en_US qmake -> make, quake, q make
qbs.x86_64: W: spelling-error %description -l en_US cmake -> cake, make, c make
qbs.x86_64: W: devel-file-in-non-devel-package /usr/bin/qbs-config
qbs.x86_64: W: devel-file-in-non-devel-package /usr/share/qbs/imports/qbs/base/qmlapplicationviewer/qmlapplicationviewer_qt5.h
qbs.x86_64: W: devel-file-in-non-devel-package /usr/share/qbs/imports/qbs/base/qmlapplicationviewer/qmlapplicationviewer_qt4.h
qbs.x86_64: W: devel-file-in-non-devel-package /usr/share/qbs/imports/qbs/base/qmlapplicationviewer/qmlapplicationviewer_qt5.cpp
qbs.x86_64: W: devel-file-in-non-devel-package /usr/share/qbs/imports/qbs/base/qmlapplicationviewer/qmlapplicationviewer.h
qbs.x86_64: W: devel-file-in-non-devel-package /usr/share/qbs/imports/qbs/base/qmlapplicationviewer/qmlapplicationviewer_qt4.cpp
qbs.x86_64: W: no-manual-page-for-binary qbs-detect-toolchains
qbs.x86_64: W: no-manual-page-for-binary qbs
qbs.x86_64: W: no-manual-page-for-binary qbs-qmltypes
qbs.x86_64: W: no-manual-page-for-binary qbs-config
qbs-cpp.x86_64: W: no-documentation
qbs-devel.x86_64: W: no-documentation
qbs-examples.x86_64: W: no-documentation
qbs-examples.x86_64: W: devel-file-in-non-devel-package /usr/share/qbs/examples/helloworld-complex/src/main.cpp
qbs-examples.x86_64: W: devel-file-in-non-devel-package /usr/share/qbs/examples/cocoa-application/CocoaApplication/AppDelegate.h
qbs-examples.x86_64: W: devel-file-in-non-devel-package /usr/share/qbs/examples/helloworld-complex/src/foo.cpp
qbs-examples.x86_64: W: devel-file-in-non-devel-package /usr/share/qbs/examples/helloworld-qt/main.cpp
qbs-examples.x86_64: W: devel-file-in-non-devel-package /usr/share/qbs/examples/collidingmice/mouse.h
qbs-examples.x86_64: W: devel-file-in-non-devel-package /usr/share/qbs/examples/collidingmice/main.cpp
qbs-examples.x86_64: W: devel-file-in-non-devel-package /usr/share/qbs/examples/helloworld-minimal/main.cpp
qbs-examples.x86_64: W: devel-file-in-non-devel-package /usr/share/qbs/examples/app-and-lib/lib/lib.cpp
qbs-examples.x86_64: W: devel-file-in-non-devel-package /usr/share/qbs/examples/helloworld-complex/src/foo.h
qbs-examples.x86_64: W: devel-file-in-non-devel-package /usr/share/qbs/examples/collidingmice/mouse.cpp
qbs-examples.x86_64: W: devel-file-in-non-devel-package /usr/share/qbs/examples/app-and-lib/app/main.cpp
qbs-examples.x86_64: W: devel-file-in-non-devel-package /usr/share/qbs/examples/helloworld-complex/src/specialfeature.h
qbs-examples.x86_64: W: devel-file-in-non-devel-package /usr/share/qbs/examples/helloworld-complex/src/specialfeature.cpp
qbs-gui.x86_64: W: no-documentation
qbs-gui.x86_64: W: no-manual-page-for-binary qbs-config-ui
qbs-qt.x86_64: W: no-documentation
qbs-qt.x86_64: W: no-manual-page-for-binary qbs-setup-madde-platforms
qbs-qt.x86_64: W: no-manual-page-for-binary qbs-setup-qt
9 packages and 0 specfiles checked; 0 errors, 35 warnings.

Regards,
Erik

New release:

- New upstream release 1.1.1

Updated SPEC: http://ablu.fedorapeople.org/qbs.spec
New SRPM: http://ablu.fedorapeople.org/qbs-1.1.1-1.fc20.src.rpm
New koji build: http://koji.fedoraproject.org/koji/taskinfo?taskID=6285847

Regards,
Erik

Decide to take it.

Please use qmake qt5 macro:

[rpmaker@fab qbs]$ rpm -E %_qt5_qmake

Ok. Will fix it tomorrow or bundle it with other stuff you find.

Thanks a lot for taking!

Regards,
Erik

SRPM: http://ablu.fedorapeople.org/qbs.spec
SPEC: http://ablu.fedorapeople.org/qbs-1.1.1-2.fc20.src.rpm
KOJI: http://koji.fedoraproject.org/koji/taskinfo?taskID=6363314

- Made use of the %%_qt5_qmake makro

Regards,
Erik

One question, do we need to separate out so many subpackages?

Generally -devel because i only need that if i want to compile my own modules against qbs,
-gui to prevent pulling in qt5-qtbase-gui with all it's dependencies where i do not want it
-examples since i usually do not really need them
-doc since it is a relatively big html doc like other qt packages have

So I guess the main question is -qt and -cpp. They both share their dependencies with the main package, so it would be generally possible to merge them into the main one. However you can generally use qbs without them. And in the future there will most likely be more packages which do not depend on either cpp or qt. And I am not sure wether it is a good idea to always keep extending the base package with all possible modules that do not have extra dependencies...

But well I am open for input here of course... (I am not that experienced in packaging)

Regards,
Erik

UPDATE:

Here are already two pending additions which would not depend on either -qt nor -cpp:

https://codereview.qt-project.org/#change,69984
https://codereview.qt-project.org/#change,55797

But the thing is: Do you really expect non-Qt projects to use qbs? If not, it's pointless to split support for Qt projects into subpackages.

Sure I do. Especially on longer term when qbs is default for Qt (just like qmake).

I also work on a project which currently uses qbs as secondary build system which I hope to be able make as primary one once qbs is more established. That project only uses c++ and not Qt.

Regards,
Erik

Hello from qbs upstream.

We certainly intend for non-Qt projects to use qbs. It has a very modular design and pretty much the only Qt-specific bits are the (qml/js) Qt modules. The majority of its selling points (speed, configurability, expressiveness, boilerplate reduction, maintainability, IDE integration) apply to any project whether it uses Qt or not and we hope that will encourage more developers to give it a try.

SRPM: http://ablu.fedorapeople.org/qbs.spec
SPEC: http://ablu.fedorapeople.org/qbs-1.2.1-1.fc20.src.rpm
KOJI: http://koji.fedoraproject.org/koji/taskinfo?taskID=7057099

- New upstream release 1.2.1
- New subpackage: nsis
- Run the autotests

Regards,
Erik

ehm... Switch SRPM and SPEC obviously...

I still don't like the current packaging way of qbs, it should only have 2 subpkgs, -devel(put -qt-devel into it) and -nsis. The others should be put into main package. I don't think users will find so many subpackages to use qbs, they just want to install and use it.

Are these useful?

/usr/share/qbs/modules/cpp/DarwinGCC.qbs
/usr/share/qbs/modules/cpp/darwin-tools.js
/usr/share/qbs/modules/cpp/ios-gcc.qbs
/usr/share/qbs/modules/cpp/linux-gcc.qbs
/usr/share/qbs/modules/cpp/msvc.js
/usr/share/qbs/modules/cpp/osx-gcc.qbs
/usr/share/qbs/modules/cpp/path-tools.js
/usr/share/qbs/modules/cpp/windows-msvc.qbs

What am I supposed to do with upcoming modules that then depend on other stuff?

Qbs is designed in this modular design. So I am not sure if it would be the best idea to throw all that away by squashing it into one big package but rather package it like it is designed by qbs.

Why would I want the Qt and Cpp Modules (and qbs commands) if I only want to compile some java?

So I am sceptical about wether putting all into one package is a good idea...

About the files: Some of them seem to be in use. But I will get into touch with upstream to figure out how I can remove the OS X / mscv related stuff.

> Why would I want the Qt and Cpp Modules (and qbs commands) if I only want
> to compile some java?

Besides that there is no -java subpkg yet, the Java developer probably will install "qbs" and notice that it's incomplete, if qbs-java and other subpackages will be needed.


The Qt Build Suite already depends on Qt and C++, and Qt is based on C++, and subpackage qbs-qt requires qbs-cpp too, so splitting off the -qt and -cpp subpkgs is questionable already.


You've created strange dependencies (or lack thereof) already, and that could become a mess in future version/feature upgrades.

qbs-devel includes some headers for Qt support:

  $ rpmls -p qbs-devel-1.2.1-1.fc21.x86_64.rpm |grep qt
  -rw-r--r--  /usr/include/qbs/qtprofilesetup.h
  -rw-r--r--  /usr/include/qbs/use_installed_qtprofilesetup.pri

That maybe is an API for the .so in the extra qbs-qt-devel,

  $ rpmls -p qbs-qt-devel-1.2.1-1.fc21.x86_64.rpm 
  lrwxrwxrwx  /usr/lib64/libqbsqtprofilesetup.so

but that 3940 bytes small package contains a single symlink only, which points at a versioned lib,

  $ rpm -qlpv qbs-qt-devel-1.2.1-1.fc21.x86_64.rpm 
  lrwxrwxrwx    1 root    root                       29 Jun 19 11:28 /usr/lib64/libqbsqtprofilesetup.so -> libqbsqtprofilesetup.so.1.2.1

and there is only the automatic soname dep for it (not even a dep on qbs-devel and no dep on qt-devel anywhere either),

  $ rpm -qpR qbs-qt-devel-1.2.1-1.fc21.x86_64.rpm |grep -v ^rpm
  libqbsqtprofilesetup.so.1()(64bit)
  qbs-qt(x86-64) = 1.2.1-1.fc21

but the actual lib is included in the base "qbs" package:

  $ rpmls -p qbs-1.2.1-1.fc21.x86_64.rpm |grep qt
  lrwxrwxrwx  /usr/lib64/libqbsqtprofilesetup.so.1
  lrwxrwxrwx  /usr/lib64/libqbsqtprofilesetup.so.1.2
  -rwxr-xr-x  /usr/lib64/libqbsqtprofilesetup.so.1.2.1
  -rw-r--r--  /usr/share/doc/qbs/html/qt-build-suite.index
  -rw-r--r--  /usr/share/doc/qbs/html/qt-modules.html
  -rw-r--r--  /usr/share/doc/qbs/html/qt-versions.html

Perhaps that's just a packaging bug, but there is no compelling reason yet why so many tiny packages have been created.

Even qbs-doc is just 70 KB and questionable to splitt of so small documentation already.

> Besides that there is no -java subpkg yet, the Java developer probably will
> install "qbs" and notice that it's incomplete, if qbs-java and other
> subpackages will be needed.
Hm. I think that would work for cpp/qt developers too.

> The Qt Build Suite already depends on Qt and C++, and Qt is based on C++, and
> subpackage qbs-qt requires qbs-cpp too, so splitting off the -qt and -cpp
> subpkgs is questionable already.
Well it only depends on the libraries but not on any development packages.
The qbs-qt and qbs-cpp packages only make a lot of sense if you also install development packages (either via the repository or by downloading from qt for example).

> You've created strange dependencies (or lack thereof) already,
Is this referring to the weirdness with the qbsqtprofilesetup lib? Or to the -qt -cpp subpackages?

> and that could become a mess in future version/feature upgrades.
Hm. At the moment I find the splitting easier than a big package... It is easier to make changes to it for me. Splitting a package later again will require a lot more work if it has a lot more modules.

Also when doing changes in one module I find it easier if I can work with a single subpackage rather than with a big "superpackage".

> Even qbs-doc is just 70 KB and questionable to split of so small
> documentation already.
Hm. I did not put size as my first criteria for the split but the structure of the architecture.

As you said: If a user finds something missing they would simply install the qbs-<subject> package which would install anything they needed and they would be set.

About the qbsqtprofilesetup library: Yes I messed that up. I fixed it now:

SRPM: http://ablu.fedorapeople.org/qbs.spec
SPEC: http://ablu.fedorapeople.org/qbs-1.2.1-2.fc20.src.rpm

Somehow rpmlint complains about a missing ldconfig post* script. But isn't it correct the way I did it?

So. About merging the packages... If you insist on it I will merge them... Even though I do not like the idea...

> Hm. I think that would work for cpp/qt developers too.

Of course. "BuildRequires: qbs" would not be sufficient in that case.

  $ qbs
  No build graph exists yet for this configuration.
  Resolving project for configuration gcc-debug
  ERROR: /home/ms20b/tests/qbs/release.qbs:3:1 Product dependency 'cpp' not found.

After installing qbs-cpp:

  $ qbs
  No build graph exists yet for this configuration.
  Resolving project for configuration gcc-debug
  ERROR: /usr/share/qbs/modules/cpp/GenericGCC.qbs:7:8 Can't find imported file /usr/share/qbs/modules/cpp/path-tools.js.

Indeed. That file is not packaged, but available in the source tarball. A bug?

Extracting that script from the tarball and installing it, I got this:

  $ qbs
  No build graph exists yet for this configuration.
  Resolving project for configuration gcc-debug
  ERROR: /usr/share/qbs/imports/qbs/base/CppApplication.qbs:4:5 Module cpp could not be loaded.

 -> More runtime testing of these "qbs" packages is needed.

[...]

Another packaging issue:

  $ rpm -qf /usr/share/doc/qbs/*
  qbs-1.2.1-2.fc20.x86_64
  qbs-doc-1.2.1-2.fc20.noarch
  qbs-1.2.1-2.fc20.x86_64
  qbs-doc-1.2.1-2.fc20.noarch
  qbs-1.2.1-2.fc20.x86_64
  qbs-doc-1.2.1-2.fc20.noarch
  qbs-1.2.1-2.fc20.x86_64
  qbs-doc-1.2.1-2.fc20.noarch

The reason is that as of Fedora 20 you cannot use %doc and %_docdir/%name, since the former includes everything below %_docdir/%name (aka the unversioned docdirs feature of F20): https://fedorahosted.org/fpc/ticket/338

    $ qbs
    No build graph exists yet for this configuration.
    Resolving project for configuration gcc-debug
    ERROR: /usr/share/qbs/imports/qbs/base/CppApplication.qbs:4:5 Module cpp could not be loaded.

Did you run `qbs-setup-toolchains --detect`? This should probably be run in the rpm's postinstall step (possibly also `qbs-setup-qt --detect`).

qbs uses a mechanism called profiles to configure the properties of different toolchains such as the location of your compiler, special compiler/linker flags, etc., and thus you must use qbs-setup-toolchains (or do it manually with qbs-config) to create these, otherwise you can't build anything.

I had run several of the qbs* commands in the various (sub)packages to find out how much they would run and whether any inter-dependencies turn up.

Running that command again doesn't change a thing:

# qbs-setup-toolchains --detect
Trying to detect gcc...
Profile 'gcc' created for '/usr/lib64/ccache/g++'.
Trying to detect clang...
clang not found.
Making profile 'gcc' the default.

$ qbs
No build graph exists yet for this configuration.
Resolving project for configuration gcc-debug
ERROR: /usr/share/qbs/modules/cpp/GenericGCC.qbs:7:8 Can't find imported file /usr/share/qbs/modules/cpp/path-tools.js.

path-tools.js shouldn't have been omitted from the package. If that file is present (unless there are others missing) and you've setup toolchains, it should work.

What project are you running this on?

And can you please list the output of qbs config --list?

I am successfully building big software like qt-creator but also qbs itself and my own projects with it. So I gave it a fair amount of runtime testing.

About running --detect in post install...

Not sure if that is a good idea... It will detect a ton of stuff, but will leave you without an default if you have more than one compiler installed.

So I think it might be better to get the user run it for him. Then he gets the feedback about the default from qbs.

Regards,
Erik

Can't RPMs ask questions on install? "qbs requires setup toolchains blah blah would you like to run that now? [y/n]"

Na. what if the package is not installed via console but a graphical system? Or if it is installed by a cronjob doing updates maybe (or as part of an system upgrade). This is not working.

> path-tools.js shouldn't have been omitted from the package.

The package from comment 36 ( http://ablu.fedorapeople.org/qbs-1.2.1-2.fc20.src.rpm ) does this:

  rm -f %{buildroot}/usr/share/qbs/modules/cpp/DarwinGCC.qbs
  rm -f %{buildroot}/usr/share/qbs/modules/cpp/darwin-tools.js
  rm -f %{buildroot}/usr/share/qbs/modules/cpp/ios-gcc.qbs
  rm -f %{buildroot}/usr/share/qbs/modules/cpp/linux-gcc.qbs
  rm -f %{buildroot}/usr/share/qbs/modules/cpp/msvc.js
  rm -f %{buildroot}/usr/share/qbs/modules/cpp/osx-gcc.qbs
  rm -f %{buildroot}/usr/share/qbs/modules/cpp/path-tools.js
  rm -f %{buildroot}/usr/share/qbs/modules/cpp/windows-msvc.qbs

No surprise the path-tools.js script is missing.

That change in the package is not mentioned in the %changelog section.

So much about having tested the package, eh? ;-)

Ah meh... I knew i forgot something... I wanted to test wether it still works without these after the first comment :P

As I said some of those are required ;)

(I did too much stuff at the same time today :/)

I am not quite sure how to fix the issue with the doc file ownership...

I can give the doc package ownership on the html subfolder only. But how do i prevent the main package from getting that too?

Also who owns the doc root directory? Right now I could install the docs without installing qbs itself and the other way round...

Regards,
Erik

The FPC ticket covers a few work-arounds.

1) If the files in the -doc package need to be stored in %_docdir/%name, you cannot use %doc magic in the base package to include files from builddir. You need to install the files into the %buildroot in %install, so you can include them via full %_docdir/%name/foo paths.

2) If the files in the -doc package may be placed in a different path, figure out whether there is an option to install the HTML docs into a specific path. Alternatively, move them at the end of %install.

Note that one common way to relocate doc files is to move them from %buildroot into builddir (e.g. from %buildroot to $(pwd)/_tmp_docs) and then use %doc magic in the subpackage %files list to include those files. For the -doc package the files will end up in %_docdir/%name-doc then, not %_docdir/%name.

Also note that a set of %exclude lines would work, too, but bears a risk of duplicating future doc files again when you forget to add new %excludes for them.


> Also who owns the doc root directory?

Both packages may own it based on:
https://fedoraproject.org/wiki/Packaging:Guidelines#The_directory_is_owned_by_a_package_which_is_not_required_for_your_package_to_function

SPEC: http://ablu.fedorapeople.org/qbs.spec
SRPM: http://ablu.fedorapeople.org/qbs-1.2.1-3.fc20.src.rpm

- Fixed file ownership of the doc package
- Removed accidently added removals of files for testing


@Michael:
Thanks a lot! I was somehow missing the "final"/"official" solution in the ticket.

I think the doc dir should be fine now.

Regards,
Erik

Few things:

- You've set QBS_LIBRARY_DIRNAME *and* QBS_QBS_LIBRARY_DIRNAME, there should be no need for the latter if you cherry-picked the patch which fixes this issue (as you appear to have done in Patch0).
- I'm not sure if it's useful to remove the IB and WiX modules. There's others that could be removed as well if we go down this route, and it's probably more hassle than it's worth to continually update that list from version to version, not to mention the risk of accidentally removing something that's needed (case in point, you already removed a thing or two by accident in an earlier dev version). Then again, it might not be as bad if you only exclude things at a module granularity rather than a file granularity. For example, remove the IB and WiX modules in their entirety but don't remove DarwinGCC from within the cpp module. Thoughts?
- Don't manually fix the permissions for the NSIS files; cherry pick 37d7dea3d3db3bd47a5e921de1cf54d48a8736d5 instead and add it as a Patch file. This fix should be in 1.2.2.

PS - You have BuildRequires nsis, don't forget to add node.js and typescript when qbs 1.3 comes around.

about double prefix: Right. I can drop that one now.

about WiX and IB: This does not make sense. These are nicely seperatable modules which are in no way ever useful on linux. So why should I make subpackages for those if they are not required? That would only be confusing.

About DarwinGCC + co: I already asked for feedback about requirement (and wether they are required part of the API) of those files on #qt-qbs (so far I got no feedback).

If they are not required I am planning to remove them.

about the permissions: I made my change before you fixed it. But yes, I could pull in your patch now. I can do it in my next iteration.

about build requires: I only need nsis as build requirement for the auto tests. If typescript / node.js are required for those in qbs 1.3 I will add them once it is releases of course to execute the tests.

Regards,
Erik

SPEC: http://ablu.fedorapeople.org/qbs.spec
SRPM: http://ablu.fedorapeople.org/qbs-1.2.1-4.fc20.src.rpm
DIFF: http://sprunge.us/FjNB?diff

- Removed some files which are not required on linux
- Use upstream patch against double prefix libdirname qmake variable
- Use upstream patch rather than fixing permission myself
- Make clear which patches are from me and which from upstream

@Jake: Fixed the issues you pointed out
@Christoper: I removed the files which are not required.

SPEC: https://ablu.fedorapeople.org/qbs.spec
SRPM: https://ablu.fedorapeople.org/qbs-1.3.0-1.fc20.src.rpm
DIFF: http://sprunge.us/BYNc?diff
KOJI: http://koji.fedoraproject.org/koji/taskinfo?taskID=7469319
(arm build still runs on koji. But that one randomly failed in the past due to too long test runs. Maybe I will have to disable the test runs there... But I need to see)

- New release 1.3.0
- New modules: nodejs, typescript


I am getting this rpmlint warning:
qbs-qt-devel.x86_64: W: only-non-binary-in-usr-lib

Though I do not understand where this comes from...
rpmls qbs-qt is:
-rwxr-xr-x  /usr/bin/qbs-setup-qt
lrwxrwxrwx  /usr/lib64/libqbsqtprofilesetup.so.1
lrwxrwxrwx  /usr/lib64/libqbsqtprofilesetup.so.1.3
-rwxr-xr-x  /usr/lib64/libqbsqtprofilesetup.so.1.3.0
-rwxr-xr-x  /usr/lib64/qbs/plugins/libqbs_qt_scanner.so

Regards,
Erik

The warning seems false here. qbs-qt-devel technically does not contain binaries in %{_libdir}, but it contains a symlink to a binary in the same directory, so the warning does not make sense.

The point of the warning is to catch stuff that installs only architecture-independent stuff into %{_libdir}, which would be better put into %{_datadir} or %{_libexecdir}. But this is not the case here, the warning is a false positive (and since it's an obvious case, it should be reported as a bug to rpmlint, really).

I really think the packaging of qbs in Fedora is over complicated.

Reassigning.

> %package typescript
> Summary:   NodeJS module for qbs

Copy&paste error there.

> The point of the warning is to catch stuff that installs only architecture-
> independent stuff into %{_libdir}, which would be better put into %{_datadir}
> or %{_libexecdir}. But this is not the case here, the warning is a false
> positive (and since it's an obvious case, it should be reported as a bug to
> rpmlint, really).
Thanks a lot for the explanation. Tagged the mail as todo so I do not forget reporting the issue against rpmlint.

> Copy&paste error there.
Thanks a lot. Fixed locally. Waiting for more severe issues for kicking off builds.

> I really think the packaging of qbs in Fedora is over complicated.
I am sorry to hear that. I was still open to take input on this subpackage splitups. But after I pointed out my points I did not receive any input on it so I sticked on it.

As you can see this new release already adds two new modules... If I would put everything into the same package I fear that it would be pretty annoying later on and splitting it later again would be a lot more complex (How could I even split out a module later? One person might need it so to prevent confusion during the update I would need to add a Requires: to it. But another person might have never used it and would end up installing the subpackage he does not need).

But still thanks a lot for all the input so far!

Regards,
Erik

Gave this a brief look over, here's some issues I've found:

- BuildRequires should probably have nodejs and typescript dependencies as there are autotests for these modules
- In several places you've written qt, this should probably be Qt
- Same with windows => Windows
- nodejs/NodeJS => Node.js
- linux => Linux
- Remove darwin-tools.js from the list of removed files because that file is no longer in that directory (and no you cannot remove it from imports)
- "# Remove the WiX-Module since it is only useful for Windows" -- not necessarily, some people have reported using WiX with Wine/Mono to build MSIs on Linux just as they do NSIS installers, and I would not consider this to be a terribly unusual use case nor do I want to artificially restrict people either (see: https://build.opensuse.org/package/view_file/GNOME:Apps:Evince:Windows:STABLE/mingw32-wix/mingw32-wix.spec?expand=1 & https://build.opensuse.org/package/show?package=wixwine&project=home%3Ahiberis%3Awix)
- You can keep the IB module removed, unlike WiX I know of virtually no one who cross compiles for OS X (or iOS from anything other than OS X) let alone HAS a Linux port of ibtool... if that ever changes we can re-evaluate :)
- ifarch x86_64 when setting the plugins path seems dangerous... what about ppc64, arm64, etc? Just set it unconditionally, no harm done there

For the subpackage split, IMHO, it is OK, though I think some users WILL be confused about Qt and C++ support not being in the main package.

Would anybody mind if I would simply leave the files:
DarwinGCC.qbs,darwin-tools.js,ios-gcc.qbs,msvc.js,osx-gcc.qbs

in the package?
I fear that maintaining this list of files will be hard and error prune. Also they are part of qbs. So what tells me that I am not breaking the package for some people who include them (maybe for targets on other operating systems)?

@WiX - Module:
Hm... That looks like a lot of work to keep this tested and maintained. There currently is no easy way to install it on fedora it seems. So I would prefer not to put that much effort into it (and each release again to test it) especially since it does not seem to be officially supported for linux.

@the ifarch thing:
Qbs plugin system always tries to load the plugins from a fixed "/lib/".
While that works on most systems it does not work on 64bit systems. Ideally this would be fixed by qbs being better at reading the right paths... I will open a bug for this on upstream.

And: it does harm since if i do this unconditionally it breaks non 64bit tests since it finds 2 cpp scanner plugins for example and fails the tests.

@Kevin:
Well that is for the people who only think of it as qmake replacement. But in fact it grows to be more than that.

Regards and thanks a lot for the input,
Erik

>>> Would anybody mind if I would simply leave the files:
DarwinGCC.qbs,darwin-tools.js,ios-gcc.qbs,msvc.js,osx-gcc.qbs in the package?
I fear that maintaining this list of files will be hard and error prune. Also they are part of qbs. So what tells me that I am not breaking the package for some people who include them (maybe for targets on other operating systems)?

Well, I brought up the same point earlier. ;) I think it's find to leave them as part of the cpp subpackage and it eases our worries upstream about something being left out.

>>> @WiX - Module: Hm... That looks like a lot of work to keep this tested and maintained. There currently is no easy way to install it on fedora it seems. So I would prefer not to put that much effort into it (and each release again to test it) especially since it does not seem to be officially supported for linux.

As a package maintainer, that's not really your responsibility. That's my responsibility as an upstream developer. You can just mark it "unsupported" and not actually add any package dependency for it... but I want to be able to use it if I feel like it. Since I'll likely remove the `condition: qbs.hostOS.contains("windows")` you technically *can't* remove it at that point because it could break user code.

>>> @Kevin: Well that is for the people who only think of it as qmake replacement. But in fact it grows to be more than that.

Correct. You could also think of it as a replacement for CMake that just happens to be implemented in Qt and that Qt just happens to plan to adopt. There's no relation to qmake other than it being developed by roughly the same group of people.

> As a package maintainer, that's not really your responsibility. That's my
> responsibility as an upstream developer. You can just mark it "unsupported" and
> not actually add any package dependency for it... but I want to be able to use
> it if I feel like it.

We have a policy in Fedora of not shipping packages that are useless without a third-party dependency:
https://fedoraproject.org/wiki/Packaging:Guidelines#Packages_which_are_not_useful_without_external_bits

(A way around this would be to ship the WiX support in the main qbs package, or together with NSIS support, because then the resulting package is not unusable without a third-party dependency.)

But IMHO, not only we shouldn't be shipping WiX support at all, but YOU as upstream shouldn't be, either. People should use NSIS instead. WiX is a typical example of "Free, but shackled".

> Since I'll likely remove the `condition: qbs.hostOS.contains("windows")` you
> technically *can't* remove it at that point because it could break user code.

There surely are ways for us around that (e.g. shipping a dummy WiX support that errors when people actually want to run WiX, which wouldn't work anyway).

> Correct. You could also think of it as a replacement for CMake that just happens
> to be implemented in Qt and that Qt just happens to plan to adopt. There's no
> relation to qmake other than it being developed by roughly the same group of
> people.

I still doubt that QBS is realistically going to be picked up outside of the Qt community.

> We have a policy in Fedora of not shipping packages that are useless without a third-party dependency:
> https://fedoraproject.org/wiki/Packaging:Guidelines#Packages_which_are_not_useful_without_external_bits
>
> (A way around this would be to ship the WiX support in the main qbs package, or together with NSIS support, because then the resulting package is not unusable without > a third-party dependency.)

We kind of keep going back and forth on this, but you might be right. We could just roll all of the module packages into the main qbs package, and add dependencies like Qt, NSIS, etc., as Recommends or Suggests or whatever it is in RPM.

> But IMHO, not only we shouldn't be shipping WiX support at all, but YOU as upstream shouldn't be, either. People should use NSIS instead. WiX is a typical example of "Free, but shackled".

Please explain why upstream shouldn't be shipping WiX support. I suppose we should remove support for Microsoft Visual C++ and all the Apple-related features too?

"People should use NSIS instead." -- well, I think people shouldn't be using NSIS, and should use WiX instead. Personal opinions are not really relevant here.

> There surely are ways for us around that (e.g. shipping a dummy WiX support that errors when people actually want to run WiX, which wouldn't work anyway).

Why do you *deliberately* want to break this?

> I still doubt that QBS is realistically going to be picked up outside of the Qt community.

We already have people using it for non-Qt projects. Regardless of opinion or expectation, this is one of the core design philosophies.

I indeed don't see a good reason to support Visual C++ either, but (like the "you shouldn't support WiX" part) that's just my personal opinion. IMHO, it's enough to support one way to compile binaries and build installers for a given target, so I don't see the point of supporting a less free and native-only alternative.

What is more relevant for Fedora is that it is kinda silly to ship (in Fedora) support for things that we do not and cannot ship because they do not support GNU/Linux at all. That said, if it is reasonably possible to get the stuff to run in WINE, our users might possibly have a use for it.

As far as I'm aware, WiX should be runnable in WINE. We support MinGW too, and I think it (WiX) could certainly be useful for Linux developers wanting to cross-compile for Windows, which is why it should be left in untouched (not to mention that attempting to replace it with a dummy or remove it is actually *more* effort and complication, both for packagers and qbs users).

Of course we want to ship the MinGW support, assuming it works with our cross-MinGW (mingw32-*/mingw64-*) packages. As for the WiX support, what it will boil down to is the optional runtime dependency on an external component, that is typically not a problem in Fedora (see Ark supporting tools like unrar, libdvdread dlopening libdvdcss etc.). Whether a -wix subpackage can be made or whether it has to be stuffed into something larger depends on how strictly the reviewer interprets the Fedora guideline I linked in comment #61. (The guideline as written is not even clear on whether it is per source package or per binary (sub)package.)

As for my personal opinion, I would like to clarify that what I have a problem with is not support for compiling FOR a proprietary platform, but support for tools that lock you into compiling ON the proprietary platform.

> As for my personal opinion, I would like to clarify that what I have a problem with is not support for compiling FOR a proprietary platform, but support for tools that lock you into compiling ON the proprietary platform.

Well, we do and will continue to support such tools, as users expect this support. You are more than welcome to use MinGW instead of MSVC.

SPEC: https://ablu.fedorapeople.org/qbs.spec
SRPM: https://ablu.fedorapeople.org/qbs-1.3.3-1.fc21.src.rpm
KOJI: http://koji.fedoraproject.org/koji/taskinfo?taskID=8609471

* Thu Dec 11 2014 Erik Schilling <ablu.erikschilling> 1.3.3-1
- New release 1.3.3
- Removed tests since it is too hard to maintain their lookup of plugins
  on different arches.

* Mon Oct 20 2014 Erik Schilling <ablu.erikschilling> 1.3.2-1
- New release 1.3.2

* Mon Sep 29 2014 Erik Schilling <ablu.erikschilling> 1.3.1-1
- New release 1.3.1
- Fixed copy paste error in typescript summary
- Fixed some words to their official use form
- Stopped removing some in theory unuseful files from the package
  This files might break projects because they are expected to be there and it
  is too annoying to maintain the list anyway
- Applied upstream patch to make running the tests easier

Regards and sorry for the delay (the tests got on my nerves each release) :(
Erik

> # Remove the IB-Module since it is only useful for OS X
> rm -rf %{buildroot}/%{_datadir}/%{name}/modules/ib
>
> # Remove the WiX-Module since it is only useful for Windows
> rm -rf %{buildroot}/%{_datadir}/%{name}/modules/wix

Delete that. This ignore list is a maintenance burden and messing with our qbs files may cause problems for end users based on how qbs works and/or if upstream changes things.

> Removed tests since it is too hard to maintain their lookup of plugins
  on different arches.

Disappointing, but I suppose it can always be re-added later... didn't we fix this issue for you though?

> # Remove the IB-Module since it is only useful for OS X
> rm -rf %{buildroot}/%{_datadir}/%{name}/modules/ib
>
> # Remove the WiX-Module since it is only useful for Windows
> rm -rf %{buildroot}/%{_datadir}/%{name}/modules/wix

Delete that. This ignore list is a maintenance burden and messing with our qbs files may cause problems for end users based on how qbs works and/or if upstream changes things.

Otherwise it'll be an endless stream of maintaining the ignore list, coordinating with upstream whether it's safe to do so for any given case... just not worth it.

> Removed tests since it is too hard to maintain their lookup of plugins
  on different arches.

Disappointing, but I suppose it can always be re-added later... didn't we fix this issue for you though? Maybe it's in master.

@Windows/OS X modules:

Na I do not think it makes any sense to include them... They are useless on linux. So if I would do a subpackage (qbs-wix for eg.) for them it would be a useless confusing package. If I would stick it into the main package it bloats that package for no good. I am trying to keep qbs as modulizable as it is provided.
Also you said that modules are fine to be removed :P

Though I am of course open for further discussions ;) In case you (upstream) somewhen plan to introduce modules which cannot be removed easily (what I do not hope). I would need to reconsider this...

@autotests:
Well it _is_ possible to run the tests, but since I seem to be the only one who runs the tests in such a setup I always hit issues when you do changes upstream. For example my old setup stopped working due to some changes and understanding why it stopped working + then opening a bugreport about it (or do countless builds to test it on my end) is a bit annoying for me at the moment.

Maybe I can setup a continuos integration which builds my package with each changeset you do would help me to catch those issues before release time... But I would need to setup this...

So: I would like to run the tests myself too, I just need to find a good maintainable way to do this.

Regards,
Erik

> Also you said that modules are fine to be removed :P

Some... it depends. Hence my concerns against using this pattern.

> Though I am of course open for further discussions ;) In case you (upstream) somewhen plan to introduce modules which cannot be removed easily (what I do not hope). I would need to reconsider this...

We've essentially already done so. In 1.4 the bundle module is only used on OS X and iOS but removing it would break all normal builds even on other platforms. It's fine for "unused" files to just go in the main package for now.

> @autotests:
Well it _is_ possible to run the tests, but since I seem to be the only one who runs the tests in such a setup I always hit issues when you do changes upstream. For example my old setup stopped working due to some changes and understanding why it stopped working + then opening a bugreport about it (or do countless builds to test it on my end) is a bit annoying for me at the moment.

If it's our fault, it's our fault. Report bugs and we'll fix them. If the tests are actually working, then they should absolutely be run as part of the rpm build.

We can maybe try to better police ourselves by testing with more configurations, too.

I started an discussion on #qt-qbs on freenode about how to handle the module thing to get some input.

About the tests: I reported all bugs I found so far (and I will report more if I find them), but at the moment I would need to figure out how to make the tests run without too much manual setting stuff. The old system was just too annoying since it relied on manual setting of the plugin paths making it fragile to changes on your end. So it is not your fault, it is just me needing to figure out a nice way to run them.

Once I find a way to run them nicely I will surely integrate them into %check again. (As an example: the old system failed when running the tests on a system which had qbs installed. So I always had to test with slow mock builds).

Regards,
Erik

Results from #qt-qbs:

A project which depends on system specific modules should not do this unconditionally if it should be buildable under different systems too.

So: I can keep the modules removed safely I think.

Regards,
Erik

Status? Also, I'll re-iterate that I don't want you maintaining an exclusions list. It's a pointless maintenance hassle and it will very likely cause problems at some point if it doesn't already.

The Debian packaging of Qbs doesn't do this (https://sources.debian.net/src/qbs/1.3.4%2Bdfsg-1/debian/rules/) and neither does the RPM packaging of CMake (http://pkgs.fedoraproject.org/cgit/cmake.git/tree/cmake.spec) similarly exclude any of its roughly-equivalent Find modules.

Status is that I forgot about the bugfix releases when i setup my continuous integration system :P

So I could give you a rpm for 1.4 but not for 1.3.3 atm :P

About the exclusions list: That list is about as hard to maintain as adding subpackages for the packages... so really easy.

Also on IRC ckandeler told me that removing entire modules is not an issue if they do not work on that platform anyway.

Otherwise I am currently a bit short on time, but I could probably try to update the package next weekend (no promises though!).

Regards,
Erik

Hey, just another reminder that it would be great to get this moving along. Qbs is already present or in progress in Debian, MacPorts, and Homebrew, let's see Fedora join the crowd. :)

Jake Patroules is interested in taking over the review request. So I am closing this one in order to allow him to open a new one (I hope this procedure is right...).

Please mark this as duplicate of Jake's when it's available.

Here's the new bug: https://bugzilla.redhat.com/show_bug.cgi?id=1262515

*** This bug has been marked as a duplicate of bug 1262515 ***