After receiving the automatic connection, lxqt-support is no longer published after being built, because binary and .so files are being found, but this wasn’t a problem before.
I want to know why the review is taking so long, and what to do to avoid this delay when a new version needs to be released.
Please avoid posting a new thread as we will lose the context of what happened before, instead replying to the existing ones.
My guess would be the store-side linter just got an upgrade to include that check, the problem might be the content interface shouldn’t be used that way without vetting its usage first.
My guess would be you haven’t complied to the previous reviewer’s request:
and thus the review task is simply being moved out of the review queue at the moment.
what to do to avoid this delay when a new version needs to be released.
You should apply for vetting the lxqt-support content snap interface’s usage as according to the following section of Process for aliases, auto-connections and tracks | Snapcraft documentation :
content - the base declaration defines that snaps that plugs the content interface will auto-connect with other snaps from the same publisher. Global auto-connect for content providers is allowed only under certain circumstances
- Rationale: because there is no tight coupling or dependency graphs between the provider and the consumer, there are no guarantees that a providing snap cannot break consuming snaps. Publishers are expected to manage breaking changes with their snaps, but are not generally expected to be concerned about others’ snaps
- Reference:
Library content interface needs special vetting as it must follow a certain interface naming requirement to ensure API compatibility, e.g. lxqt-support-2-core24
It seems that you did filed an interface request here:
However I believe at the time the @reviewers didn’t recognize that you intend to ship binaries in the content interface and treated it as a regular content interface request(e.g. icons, themes, and other non-binary resources).
I would suggest filing another content interface request with proper interface naming so that API compatibility can be ensured.
Is that what you’re talking about?
So, in that case, nobody researched what lxqt-plugin and Kvantum were before voting?
Yes.
I believed so, the @reviewers are likely tasked to check whether the interface usage fits the general purpose, but it won’t cover advanced details like ABI compatibilities which requires to actually look into the content of content snaps.
But again, I’m not one of them so I have no idea.
Refer https://forum.snapcraft.io/t/the-content-interface/1074#p-5022-sharing-a-c-level-library-2 for the principles of naming a content provider snap.
Hey folks,
As discussed in:
Traditionally, global auto-connection for content interfaces always required of publisher vetting. Earlier this year we introduced a new check in review-tools to remove the need for publisher vetting if no binaries or libraries are exposed by the content interface. This enabled snap publishers to create theme snaps even if they are not the upstream of the theme itself.
In this case, granting global auto-connection would require of publisher vetting. As per the information in your request, you are not the upstream of the snap. Thus, to continue with this request, either the upstream decides to published the snap themselves or you are added as member of the upstream.
I’m removing the global auto-connection, so that the snap can pass automatic review in the meantime
Thanks for the explanation!
I unable to locate relevant info in the content interface section of https://snapcraft.io/docs/process-for-aliases-auto-connections-and-tracks , can the process be updated to include them?
Does that mean that the content snap can still be published but will require the user to manually connect them from the consumer snap?
I unable to locate relevant info in the content interface section of https://snapcraft.io/docs/process-for-aliases-auto-connections-and-tracks , can the process be updated to include them?
Sure!
I’m removing the global auto-connection, so that the snap can pass automatic review in the meantime
Yes, that’s my expectation
This request has not been added to the review queue. It should be placed in the appropriate store-requests subcategory using the subcategory template for classic-confinement, privileged-interfaces and aliases requests.
Now I’ve managed to publish it.
But the function of the lxqt-support snaps is precisely to serve as a kind of “kf6-core for lxqt.”
What would be the solution for this? To be able to publish the lxqt-support snaps with them connecting automatically?
You content snap seems to be a combination of:
This causes complexities as now there are at least two upstream projects that need to endorse you in order for the global auto-connection application to proceed(one is already hard enough, two at the same time is nearly impossible).
I would suggest splitting the content snaps into two, it won’t help much with this problem but seems to be a logical thing to do to reduce the complexities and allow consumer snaps to only depend on one of them.
You can also workaround the lack of auto-connection by detecting the lack of connection in runtime, and proactively instruct the user to manually connect the interface to enable the app’s functionality(e.g. via Inform users with custom dialogs or Sending desktop notifications from a snap ).
The lxqt-support snaps offer the lxqt-plugin, which is a platform theme. Snaps that use kf6-core have access to both the KDE and gtk3 platform themes. Lxqt-support also offers Kvantum, which is basically a Qt style. Snaps that use kf6-core have access to the Qt Breeze and Oxygen styles.
Specifically requiring LXQT and Lubuntu users to use commands just to do what KDE users already do without commands is not user-friendly.
Sorry if I misunderstood, I’m using a translator, but basically, in order to receive the automatic connection, do I need the people responsible for LXQT and Kvantum to support the existence of lxqt-support snaps?
Like, if I talk to them and they support the existence of lxqt-support snaps, is that enough?
Can’t these two components be separated into two content snaps? As I said before this only complicates the publisher vetting process.
I’m not one of the @reviewers so I can only quote what they claimed to be the criteria:
You’ll either have to:
I guess “support the existence of lxqt-support snaps” might also help, though it really depends on how the @reviewers interpret the upstream’s response.
As I said before this is just a workaround that can be served as a stop-gap solution to this problem.
The KDE content snaps are directly published by the KDE upstream, hence they don’t have to go through that much of trouble.
I put the lxqt-plugin and kvantum in the same Snap because Lubuntu comes with Kvantum.
This makes building the content snap easier, since it’s a single snap, which also simplifies adding the necessary variables.
