qt 4.8.7 build 3 renamed moc to moc-qt4, breaks software

[davidslac]

I just built an environment that depends on qt4. It picked up qt 4.8.7_3 from defaults. This build seems to rename the bin/moc file to bin/moc-qt4. This brakes software that depends on the qt package that used the moc program. My previous environment used qt 4.8.7_1, build 1, where the executable was just called moc - this seems like a big change for a build number. You can see this change from the file list in conda-meta, and trying to run moc in the respective environments.

We are excited about conda, but I run into problems because conda changes from version to version, and a package in defaults changes. I need to isolate our production installation from these changes until I can test them more - so this is a simple question, how can I programmatically query the package list in defaults, and download what I want - including versions of conda, conda-build, conda-env. Specifically what is the URL I would use, I'm thinking I will set up my own file based channel of the packages from defaults that I want to use in production - I could just download the packages from defaults in a development environment, and move them, but in this scenario, I would look for the downloaded packages in the environment pkgs area, and trust that they are the same thing I got from defaults - which they won't be if I download the same package name from a different channel before I copy

[ccordoba12]

We are preparing to introduce Qt5 packages in the default channels. Since Qt4 and Qt5 can be installed side by side, we have decided to add a suffix to Qt4 executables so they don't clash with the Qt5 ones, which have the exact same name. Unfortunately, Qt doesn't do anything to disambiguate these programs, so we have to do it by ourselves.

Sorry for the inconvenience, but we are following the same approach several Linux distributions do to support Qt4 and Qt5 in the same environment. You can easily support either Qt4 or Qt5 in your packages by:

1. Using conda-build and depending on one or the other (once Qt5 is out, of course :-)
2. Renaming moc-qt4 or moc-qt5 to moc temporarily in your recipe (i.e. in build.sh)
3. Remove it after your package has been built (at the end of build.sh)

This is the approach we take now to build PyQt4 and it works quite well.

[davidslac]

Thanks, I should be able to adjust. My use case is that users may write
qt applications with our software. Our software provides a scons based
build system that takes care of some details. The scons build system
currently looks for 'moc' if a user is writing a qt4 app. I'd like to
package our software as a conda pacakge. We would then provide it within
a conda environment. That is, users may develop their qt apps within a
conda environment, as opposed to just needing to use the 'moc' tool
during conda-build. That is, this change is requiring me to either pinn
our dependency on qt4 to a specific build number, or dig into this scons
build system I'm trying to migrate and see if it can handle the
modernization. It should be able to, and from what you are saying it
sounds like a good thing to do, adding qt4 vs qt5.

I have this broader problem that when I pick up the latest conda or
latest version of a package, something can brake (I guess everyone can
have this problem :). I don't think this happens for the typicaly user,
someone managing their own software stack in their home directory. I
think I'm going to have to build some more complicated process where we
try to vet changes from conda defaults before incorporating them.
Anyways, if there is anything you can do to make that easier, that would
be helpful. For instance if conda asks me if I want to upgrade to a
newer version, it would be nice if there was link right there to get a
description of the changes to the software, or if conda had a
'list-changes' command for a package, or maybe this could be a tool in
new package I get.

best,

David

On 06/26/16 22:58, Carlos Cordoba wrote:

We are preparing to introduce Qt5 packages in the default channels.
Since Qt4 and Qt5 can be installed side by side, we have decided to
add a suffix to Qt4 executables so they don't clash with the Qt5 ones,
which have the exact same name. Unfortunately, Qt doesn't do anything
to disambiguate these programs, so we have to do it by ourselves.

Sorry for the inconvenience, but we are following the same approach
several Linux distributions do to support Qt4 and Qt5 in the same
environment. You can easily support either Qt4 or Qt5 in your packages by:

1. Using conda-build and depending on one or the other (once Qt5 is
   out, of course :-)
2. Renaming |moc-qt4| or |moc-qt5| to |moc| temporarily in your
   recipe (i.e. in |build.sh|)
3. Remove it after your package has been built (at the end of |build.sh|)

This is the approach we take now to build PyQt4 and it works quite well.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#26 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AQAThecqvFj2-62BaH31cHWq-tmJRSd3ks5qP2ZugaJpZM4I-nyM.