I’d like to also request global auto connect be allowed for the content snap kde-frameworks-5-core18
This uses an older Qt and KDE Frameworks than the `kde-frameworks-5-qt-5-14-core18 one but is otherwise the same.
It is used for the kde-neon extension which is used by a few Snaps.
Thank you for making this request.
@reviewers - like with kde-frameworks-5-qt-5-14-core18, while kde-frameworks-5-core18 does not follow our current guidelines for naming, which is typically <thing>-<version>-<ABI-hint>, I don’t think that is a problem. To date, this has not been an issue since the KDE team is free to name their private content anything they want.
The snapcraft.yaml does use this for the content attributes in its slot declarations:
content: kde-frameworks-5-67-qt-5-14-core18content: kde-frameworks-5-core18-allFor the same reasons as the kde-frameworks-5-qt-5-14-core18 snap, the name of the snap and the value of the “content” attribute in the two slots of the snap are conveying everything we require IMO.
@jriddell - I noticed that the names of the kde-frameworks-5-qt-5-14-core18 and kde-frameworks-5-qt-5-14-core18 snaps and the content attributes of the “-all” slot in this snap and the kde-frameworks-5-qt-5-14-core18 are not consistent with each other.
Eg, where kde-frameworks-5-qt-5-14-core18 has:
content: kde-frameworks-5-68-qt-5-14-core18 (fine)content: kde-frameworks-5-qt-5-14-core18-all (inconsistent)kde-frameworks-5-core18 has:
content: kde-frameworks-5-67-qt-5-14-core18 (fine)content: kde-frameworks-5-core18-all (inconsistent)Why does kde-frameworks-5-qt-5-14-core18 include ‘qt-5-14’ in its name and ‘-all’ slot, but kde-frameworks-5-core18 does not? Should kde-frameworks-5-core18 include ‘neon’ somewhere in the name?
@jriddell - can you or someone authoritative as the KDE publisher comment on the stability of the libraries, APIs, ABIs, etc of this snap and provide any additional information related to the promise of updates to this snap not breaking 3rd party publishers?
Finally, @jriddell - do you plan to create other coreX variations of this snap? If so, will the updates follow a format as described in my last question of comment 4 from the kde-frameworks-5-qt-5-14-core18 request?
Thanks!
@jriddell I know that quite a few developers are itching to use the kde-neon extension. So I’d be very thankful if you could comment on those formal issues raised by @jdstrand.
The snap has a number of slots which just point to the same content as the main snap. This was an attempt to create backwards compatible snap interfaces but I don’t think it’s useful and don’t expect to use them or add any more. I can delete them if you think best.
The libraries used in the snap are all ABI and API stable except as I mentioned in the other request libexiv2 did get updated to a new version in one rebuild I did, so should this ever need a rebuild I’ll make sure not to allow new versions in there.
I expect to make core20 versions of this snap in the future and will follow the naming scheme you advise.
@jriddell - I’m happy to defer to you on this point since you know your existing consumer snaps better. Assuming the votes are in the affirmative to grant auto-connect, I would like any changes to be made prior to granting the global auto-connection if you decide to change the snap. Can you comment one way or another if you are going to remove/rename one of the slots? If so, when do you expect that change to be made?
@jdstrand, +1 to allow global auto-connection for this snap from me, too.
+1 from me for global auto-connect for this snap
No I don’t expect to change the slots now
Seven days have passed since the voting started. Is it time to tally the vote?
PS: Apologies for the nagging but the new release of Krita is waiting for this auto-connection.
3 votes for, 0 against. Granting global auto-connect to this snap for both “kde-frameworks-5-67-qt-5-14-core18” and “kde-frameworks-5-core18-all”. This is now live.
Wo-hoo! 