Opened 4 years ago

Closed 3 years ago

#48184 closed submission (wontfix)

[NEW] kf5-attica

Reported by: mkae (Marko Käning) Owned by: mkae (Marko Käning)
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc: RJVB (René Bertin), kurthindenburg (Kurt Hindenburg)
Port: kf5-attica

Description

Now that a concurrent qt5-mac is in place I wanted to introduce the first KF5 port, but although kf5-attica installs, it has a problem with file system violation:

$ sudo port install
--->  Computing dependencies for kf5-attica
--->  Fetching archive for kf5-attica
--->  Attempting to fetch kf5-attica-5.11.0_0.darwin_13.noarch.tbz2 from http://nue.de.packages.macports.org/macports/packages/kf5-attica
--->  Attempting to fetch kf5-attica-5.11.0_0.darwin_13.noarch.tbz2 from http://lil.fr.packages.macports.org/kf5-attica
--->  Attempting to fetch kf5-attica-5.11.0_0.darwin_13.noarch.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/kf5-attica
--->  Staging kf5-attica into destroot
Warning: violation by /opt/local/mkspecs
Warning: kf5-attica violates the layout of the ports-filesystems!
Warning: Please fix or indicate this misbehavior (if it is intended), it will be an error in future releases!
--->  Installing kf5-attica @5.11.0_0
--->  Activating kf5-attica @5.11.0_0
--->  Cleaning kf5-attica
--->  Updating database of binaries
--->  Scanning binaries for linking errors
--->  No broken files found.

Any idea what could be done to fix this problem?

Attachments (4)

kf5-1.0.tcl (8.6 KB) - added by mkae (Marko Käning) 4 years ago.
Current status of kf5 port group making use of specific variable settings to define what the project's type is.
Portfile (410 bytes) - added by mkae (Marko Käning) 4 years ago.
The corresponding short Portfile for kf5-attica.
Portfile-kjs (467 bytes) - added by mkae (Marko Käning) 4 years ago.
kjs' Portfile as an example for a porting aid.
Portfile-kf5-kdoctools (659 bytes) - added by mkae (Marko Käning) 4 years ago.
Don't know why (suddenly) kf5-kdoctools installs its files catalog files in the Linuxy location instead of below /Library/Application Support/ as instructed in kf5-1.0 port group

Download all attachments as: .zip

Change History (23)

comment:1 Changed 4 years ago by mkae (Marko Käning)

Thanks to feedback on dev-ML I could come up with an improved Portfile, which makes use of the new port group 'kf5'.

comment:2 Changed 4 years ago by mkae (Marko Käning)

Owner: changed from macports-tickets@… to mk@…

comment:3 Changed 4 years ago by RJVB (René Bertin)

You're probably better acquainted with building KF5 most all on here, but be careful that you don't end up duplicating lots of stuff. IF KF5 has a single versioning scheme for all or at least a good part of its frameworks that gets built through the kdesrc-or-what's-it-called script, I'd strongly advise to use your KDE/CI experience to coerce that script into a portfile.

There *must* be a KF5 "subset" (a collection of frameworks) that one will have to install anyway in order to run a productivity application (KDevelop, KDE PIM, digiKam, ...).

Introducting countless individual ports one by one that each provide a single framework that is of no use in itself seems like an approach that won't attract a lot of interest. A single port that builds an ensemble that makes sense (= that you can do something with) seems a lot more interesting as a target to collaborate on.

That approach should also allow you to move stuff (name, description, version, probably a bunch of the configure args) out of the kf5 portgroup because they relate only to building KF5 and not building dependents (say, digiKam). Alternatively, you'd probably want to rename the portgroup to something that makes it clear it's an internal include file, not something to be used by any other port that provides an application that depends on KF5.

comment:4 in reply to:  3 ; Changed 4 years ago by mkae (Marko Käning)

Replying to rjvbertin@…:

You're probably better acquainted with building KF5 most all on here, but be careful that you don't end up duplicating lots of stuff.

I am still in the process of setting up all those KF5 port files here. (I am in tier 3 by now.)

Believe me, I don't want to duplicate anything unnecessarily, which is why I created the kf5 port group.

Yes, at the moment this port group is only taking care of frameworks, but I want to allow also normal projects depending on some variables set before the PortGroup command (a la ${KF5_PROJECT} - which will change meaning soon).

Alternatively I could create two port groups one called kf5-framework and the other kf5-project. I guess that needs discussion on the dev-ML...

... I'd strongly advise to use your KDE/CI experience to coerce that script into a portfile.

For testing I have half-automatically created about 20 port files now. Of course I will come up with some helper scripts to create the required portfiles. See Haralf Fernengel's HB github repo!.

There *must* be a KF5 "subset" (a collection of frameworks) that one will have to install anyway in order to run a productivity application (KDevelop, KDE PIM, digiKam, ...).

Yes, there is, but the subset is built up of all those little KF5-ports. Every project has its own subset depending on its specific requirements.

Introducting countless individual ports one by one that each provide a single framework that is of no use in itself seems like an approach that won't attract a lot of interest. A single port that builds an ensemble that makes sense (= that you can do something with) seems a lot more interesting as a target to collaborate on.

Well, in the end I could create meta-ports which might perhaps build the individual tiers of the KF5 frameworks.

That approach should also allow you to move stuff (name, description, version, probably a bunch of the configure args) out of the kf5 portgroup because they relate only to building KF5 and not building dependents (say, digiKam). Alternatively, you'd probably want to rename the portgroup to something that makes it clear it's an internal include file, not something to be used by any other port that provides an application that depends on KF5.

See above, the current state of the portfile and port group are only transitional and things will change!

Last edited 4 years ago by mkae (Marko Käning) (previous) (diff)

comment:5 in reply to:  4 ; Changed 4 years ago by RJVB (René Bertin)

Replying to mk@…:

Alternatively I could create two port groups one called kf5-framework and the other kf5-project. I guess that needs discussion on the dev-ML...

kf5-internal and kf5? Not that the Qt portgroups don't have a variable that indicates whether the port itself is building (= they do) ... but I think a single kf5 portgroup would become more complex than necessary/good-for-it that way.

... I'd strongly advise to use your KDE/CI experience to coerce that script into a portfile.

For testing I have half-automatically created about 20 port files now. Of course I will come up with some helper scripts to create the required portfiles. See Haralf Fernengel's HB github repo!.

There's always the possibility to generate a slew of subports programmatically, but that would make sense only if all those subports have the same dependencies.

Yes, there is, but the subset is built up of all those little KF5-ports. Every project has its own subset depending on its specific requirements.

That the subset is built up out of a trazillion KF5 morsels isn't an issue as long as there's a script (like I understand there is) that takes care of building them as if they were a whole. That each KF5 "client" application depends on its own individual subset isn't an issue either. Declaring a dependency on port:kf5 doesn't mean you have to link in all those frameworks (just like depending on port:qt5-mac doesn't mean you link with all Qt components.

Again, suppose it turns out that you end up installing just about all KF5 frameworks when you actually want to install systemsettings5, kate, konsole, KDevelop, KDE PIM, kdesvn and digiKam (just to name the ones I use regularly). In that case, isn't it much easier to have only a single port they need to depend on?

There *is* a kdesrc script that supposedly takes care of the whole build process, no?

Well, in the end I could create meta-ports which might perhaps build the individual tiers of the KF5 frameworks.

Hmmm, and in true hipster fashion you'd be doing that at a table in the Restaurant at the End of the Universe? ;)

comment:6 Changed 4 years ago by mf2k (Frank Schima)

Keywords: haspatch removed

There is no need to use a keyword for a submission ticket.

comment:7 in reply to:  5 Changed 4 years ago by mkae (Marko Käning)

Replying to rjvbertin@…:

kf5-internal and kf5?

Or kf5-frameworks and kf5?

a single kf5 portgroup would become more complex than necessary/good-for-it that way.

Yep.

There's always the possibility to generate a slew of subports programmatically, but that would make sense only if all those subports have the same dependencies.

If I - perhaps - create a script for this job it would do everything programmatically. I believe that Harald's scripts also do that using KDE's dependency information.

Declaring a dependency on port:kf5 doesn't mean you have to link in all those frameworks (just like depending on port:qt5-mac doesn't mean you link with all Qt components.

Good point. But still, if you do it on a fine-granular level you only include a few kf5 ports instead of the whole set of 60 frameworks.

Again, suppose it turns out that you end up installing just about all KF5 frameworks when you actually want to install systemsettings5, kate, konsole, KDevelop, KDE PIM, kdesvn and digiKam (just to name the ones I use regularly). In that case, isn't it much easier to have only a single port they need to depend on?

I agree there. Let's see how it works out, if I find more time to deal with this submission... It's not top prio for me ATM, as you know. :)

There *is* a kdesrc script that supposedly takes care of the whole build process, no?

Yes, but I am not using that.

Hmmm, and in true hipster fashion you'd be doing that at a table in the Restaurant at the End of the Universe? ;)

At table No. 42, of course. ;)

comment:8 Changed 4 years ago by mkae (Marko Käning)

My Portfile-generating bash-script is able to build up to tier 3. I am stopped at kf5-knotifications, as phonon-qt5 is still making trouble due to current (concurrent) qt5-mac...

comment:9 Changed 4 years ago by RJVB (René Bertin)

Are you still interested in a dedicated qt5-kde port (presumably with its own PortGroup file just so we can be our own control freaks)?

comment:10 Changed 4 years ago by mkae (Marko Käning)

Yes, absolutely!

I will formulate the kf5-framework and kf5 port groups in such a way, that they accept qt5-kde as well as qt5-mac, since I hope that one day the latter will also be capable to deal with what your version can do. :)

comment:11 Changed 4 years ago by RJVB (René Bertin)

Well, that's the role of the PortGroup file, ensuring that a Qt5 dependent port can accept either flavour of the Qt5 ports.

Shouldn't take me very long, but I have a few other real-life things on my plate that have to get priority (in addition to a "survive the current heatwave" project :-/)

comment:12 in reply to:  11 Changed 4 years ago by mkae (Marko Käning)

Replying to rjvbertin@…:

Well, that's the role of the PortGroup file, ensuring that a Qt5 dependent port can accept either flavour of the Qt5 ports.

Yep.

Shouldn't take me very long, but I have a few other real-life things on my plate that have to get priority (in addition to a "survive the current heatwave" project :-/)

Dito and dito - here. :-/

comment:13 Changed 4 years ago by mkae (Marko Käning)

I have all 61 KF5 frameworks building here locally by now, so this is only an example for the rest of it, including porting aids. The only complication is that I need a specific version of the phonon port, see #46552, where the post-patch phase is commented out.

Changed 4 years ago by mkae (Marko Käning)

Attachment: kf5-1.0.tcl added

Current status of kf5 port group making use of specific variable settings to define what the project's type is.

Changed 4 years ago by mkae (Marko Käning)

Attachment: Portfile added

The corresponding short Portfile for kf5-attica.

comment:14 Changed 4 years ago by mkae (Marko Käning)

Ooops, had to update the two files once more, since I uploaded old files previously.

Changed 4 years ago by mkae (Marko Käning)

Attachment: Portfile-kjs added

kjs' Portfile as an example for a porting aid.

Changed 4 years ago by mkae (Marko Käning)

Attachment: Portfile-kf5-kdoctools added

Don't know why (suddenly) kf5-kdoctools installs its files catalog files in the Linuxy location instead of below /Library/Application Support/ as instructed in kf5-1.0 port group

comment:15 Changed 4 years ago by mkae (Marko Käning)

I am close to give up on KF5 for now, as I have no clue why it suddenly fails to install the files in the correct OSX'ish location... :-(

comment:16 Changed 3 years ago by kurthindenburg (Kurt Hindenburg)

Cc: khindenburg@… added

Cc Me!

comment:17 Changed 3 years ago by kurthindenburg (Kurt Hindenburg)

MK, have you uploaded any of your KF5 ports anywhere? I don't see them in https://svn.macports.org/repository/macports/users/mk

I currently have most (5.14) of the lower tiers installed via kdesrc-build.

comment:18 in reply to:  17 Changed 3 years ago by mkae (Marko Käning)

Hi Kurt,

Replying to khindenburg@…:

MK, have you uploaded any of your KF5 ports anywhere? I don't see them in https://svn.macports.org/repository/macports/users/mk

yes, but as mentioned in my KDE-MAC post on KF5 on OSX the repo with the portfiles resides on KDE's infrastructure.

Greets, Marko

comment:19 Changed 3 years ago by mkae (Marko Käning)

Resolution: wontfix
Status: newclosed

I've stopped working on this (for now), as René is in the process of setting up a more general approach (including his XDG patch) to this in his macstrop repository.

Note: See TracTickets for help on using tickets.