search

RJVB / macstrop

RJVB's repository of alternative macports, with ports missing from or overriding those in the standard collection, including a set of KF5 ports.
20 stars 9 forks source link

Building kf5-kate #9

Closed s1bit closed 6 years ago

s1bit commented 7 years ago

While installing qt5-qtbase I get this: main.log.txt So, the problem is installed qt5-kde, which seems to conflict with qt5-qtbase. However, the both ports are ones that kf5-kate depends on.

RJVB commented 7 years ago

This most likely means you messed up something somewhere. Did you follow the instructions to copy the Qt5 portgroups from my repository into the main portgroup directory?

Your logfile doesn't show why the attempt is made to install port:qt5-qtbase. My guess is that one of the non-KF5 dependencies of port:kf5-kate also depends on Qt5, and that will lead to installing port:qt5-qtbase (etc) when my portgroups are not installed in the main repository.

It's confusing, the ports from a local repository override ports from the main repository that have the same name, but the only portgroups with "global" scope are the ones from the main repo, and they cannot be overridden globally.

IOW, if a Portfile contains a line

PortGroup qt5 1.0

it will include with either the qt5-1.0.tcl file from the _resources/port1.0/group directory in the same tree, or if that file doesn't exist, the same file from that directory in the main repo.

s1bit commented 7 years ago

This most likely means you messed up something somewhere. Did you follow the instructions to copy the Qt5 portgroups from my repository into the main portgroup directory?

Apparently I've messed up something. Otherwise it would work I believe. I did copy your portgroup files (all of them, in fact) to var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/group. Is that the correct destination?

RJVB commented 7 years ago

On Sunday June 25 2017 14:36:53 CodeTourist wrote:

Looks like it could be; did it have qt5-1.0.tcl, qmake5-1.0.tcl, cmake-1.0.tcl etc.? In this case the best way to test would be

> port dir qt5-qtbase

Do you see qt5-qtbase in the output of port rdeps kf5-kate and if so, where?

R.

s1bit commented 7 years ago

Looks like it could be; did it have qt5-1.0.tcl, qmake5-1.0.tcl, cmake-1.0.tcl etc.?

Yes, it has all of that.

port dir qt5-qtbase

/testports2/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/aqua/qt5

Do you see qt5-qtbase in the output of port rdeps kf5-kate and if so, where?

No, there is no qt5-qtbase.

RJVB commented 7 years ago

On Sunday June 25 2017 14:56:58 CodeTourist wrote:

No, there is no qt5-qtbase.

Then I'm afraid I'll have to ask you to uninstall port:qt5-qtbase and clean port:kf5-kate, and then repeat the attempt to install kf5-kate. I'll need to see the entire log to understand where you ended up installed qt5-qtbase...

s1bit commented 7 years ago

So, if I start with no ports installed: $ port rdeps kf5-kate ... phonon-qt5   qt5-qtbase     gawk   qt5-qttools     qt5-qtxmlpatterns     qt5-qtdeclarative     qt5-sqlite-plugin ...

What about adding 'set qt5.prefer_kde 1' to the phonon portfile?

RJVB commented 7 years ago

On Monday June 26 2017 12:14:18 CodeTourist wrote:

Did you uninstall everything, or deactivate everything?

phonon-qt5 is not a direct dependency of kf5-kate, so how did you get at it? When I look at the Kate rdeps I see phonon-qt5 via kf5-kinit -> kf5-kio ->kf5-knotifications -> phonon-qt5 .

Is there any difference when you do the following?

> port rdeps kf5-kate +qt5kde

What about adding 'set qt5.prefer_kde 1' to the phonon portfile?

That I could do - but have you checked if that solves the issue? NB: I still don't know what why qt5-qtbase was pulled in originally, also because of phonon-qt5?

It still doesn't make a lot of sense, though. First, it shouldn't be necessary if you follow the recommended method of installing qt5-kde first. That's my biggest concern here: as far as I understand you had qt5-kde installed when you ran into the conflict.

You don't (didn't) happen to have a directory ${prefix}/libexec/qt5/plugins by any chance?

s1bit commented 7 years ago

Did you uninstall everything, or deactivate everything?

I started with a brand new MacPorts installation.

phonon-qt5 is not a direct dependency of kf5-kate, so how did you get at it? When I look at the Kate rdeps I see phonon-qt5 via kf5-kinit -> kf5-kio ->kf5-knotifications -> phonon-qt5 .

Sorry, I skipped the full tree. Yes, it's kf5-kinit -> kf5-kio -> kf5-knotifications -> phonon-qt5 -> qt5-qtbase.

Is there any difference when you do the following? port rdeps kf5-kate +qt5kde

Yes, there is no qt5-qtbase, qt5-qttools in the tree.

That I could do - but have you checked if that solves the issue?

I've checked. It does solve the issue.

It still doesn't make a lot of sense, though. First, it shouldn't be necessary if you follow the recommended method of installing qt5-kde first. That's my biggest concern here: as far as I understand you had qt5-kde installed when you ran into the conflict.

Yes, it shouldn't be necessary if I had qt5-kde installed. But I started with zero ports installed. I typed 'port install kf5-kate'. With the phonon portfile fix I got it through without an error (for the first time).

RJVB commented 7 years ago

On Tuesday June 27 2017 13:23:55 CodeTourist wrote:

Yes, it shouldn't be necessary if I had qt5-kde installed. But I started with zero ports installed. I typed 'port install kf5-kate'. With the phonon portfile fix I got it through without an error (for the first time).

OK, that solves the mystery, to some extent. MacPorts is "clever" enough to avoid recalculating dependencies each time a port is installed, but not enough to know when it does have to recalculate. How could it...

Note that it is not a big secret that installing dependencies explicitly can sometimes be a good idea, for instance to avoid certain install variants from propagating.

Thanks to your experience (and patience) I have now updated my instructions to indicate that the recommended procedure is to install port:qt5-kde first, but that you can also provide the +qt5kde variant explicitly during the initial install.

I haven't yet decided if I am going to implement your fix. It's true that Phonon is a KDE product, but it could have wider application, it's not one of my own ports and making it pull in port:qt5-kde when installed from scratch feels a bit off.

s1bit commented 7 years ago

Note that it is not a big secret that installing dependencies explicitly can sometimes be a good idea, for instance to avoid certain install variants from propagating.

I tried that at some point also. But there was the qttools port among the dependencies and I installed it first...

Thanks to your experience (and patience) I have now updated my instructions to indicate that the recommended procedure is to install port:qt5-kde first, but that you can also provide the +qt5kde variant explicitly during the initial install.

Yes, I noticed that when you wrote that there was a 'recommended' way to install kf5 ports. Thank you for your work on the project! How far do you think kf5 stuff from including into the official port repository?

RJVB commented 7 years ago

On Thursday June 29 2017 19:23:39 CodeTourist wrote:

I tried that at some point also. But there was the qttools port among the dependencies and I installed it first...

What exactly do you mean? Qttools is a build dependency for all KF5 ports, but is provided by qt5-kde. Evidently you will run into issues when you install port:qt5-qttools first, because that will also give you port:qt5-qtbase etc.

How far do you think kf5 stuff from including into the official port repository?

I have the impression it isn't exactly getting any closer to that (= no movement or sound for months now).

s1bit commented 7 years ago

Hello.

Qttools is a build dependency for all KF5 ports, but is provided by qt5-kde.

I did not know that and since qttools was one of the dependencies, I installed it. Anyway, it does not matter now.

I have the impression it isn't exactly getting any closer to that (= no movement or sound for months now).

Doesn't sound very promising... Well, I could try to help a bit.

RJVB commented 7 years ago

On Saturday July 08 2017 08:07:06 CodeTourist wrote:

I have the impression it isn't exactly getting any closer to that (= no movement or sound for months now).

Doesn't sound very promising... Well, I could try to help a bit.

All help is welcome, and the more people use my ports the more traction they get which ought to help too. But what I need most is someone to assist in the submission process, preferably someone with commit rights to the MacPorts tree repository. I do have a co-maintainer who's role that is/was, but I haven't been hearing from him for quite a while now.