Developer Environment
Closed, ResolvedPublic
Actions

Description

Getting into KDE development is too hard. We need some SDK thing.

Thought is having an SDK component in appstream which is extended by suitable apps (kdevelop, kate whatever).

In addition we'd auto-generate a package based on the component information where we simply choose and pick what should be part of a default SDK

Proposed Solution

Application side

In discover we want a KDE Development Environment "application" which in fact is not an application, but a fake component representing the concept of an application bundle. Actual applications add on to this component to get listed as addon options in stores as useful bits for KDE development.

Distribution side

On the distribution side the KDE Development Environment component needs to be shipped in some package. In addition this package needs to:

install relevant dev packages
install relevant default picks for the environment out of the list of components that add on to the environment

Default Installation (package deps or recommends)

all dev packages of qt
all dev packages of kf5
gcc and friends
cmake
git
plasma-sdk
kdevelop
kate

Related Objects
Search...

		Status	Assigned	Task
		Open	None	T4694 KDE Development ISO
		Resolved	sitter	T3722 Developer Environment

sitter created this task.Sep 13 2016, 1:13 PM

@mak do you have a good idea of how to implement this based on appstream?

Hard thing to do, because we only allow components of type addon to extend anything, so this can not work (changing that assumption would be massive breakage which I don't want to do).

What you could have though is a custom category for the KDE SDK pieces.

Alternatively, and that's what you have in mind I guess, one could collect the component IDs of everything that should be in the SDK, ask AppStream for the packages those map to, and build a metapackage from that information, containing a "fake" AppStream component of type "desktop-application" which describes the SDK pieces it depends on.

Would be kind of a hack though, especially pretending to be an application while not really being one is kind of meh.

@mak something between addon and what you alternatively sugggested. We want everything to be able to be listed in the "SDK" in discover as an addon one can install. Distinct from that there would be a package that solves the distribution side of things (installing -dev packages and whatnot). The default applications installed by this package would be (a subset of) all componentid's packages that addon to the SDK.

e.g.
org.kde.kate addons to org.kde.sdk
org.kde.kdevelop addons to org.kde.sdk
org.kde.cuttlefish addons to org.kde.sdk

In some packaging magic we resolve org.kde.kate as kate and org.kde.kdevelop as kdevelop and add those two as Depends: of the sdk package. We do not whitelist cuttlefish because we don't think it is a good default pick

End result being that installing SDK will install kate and kdevelop, additionally discover will list cuttlefish as addon for the SDK, but it won't be installed by default.

sitter updated the task description. (Show Details)Sep 23 2016, 11:19 AM

sitter moved this task from Discussing to Doing on the Neon board.Oct 7 2016, 9:21 AM

sitter claimed this task.

sitter renamed this task from SDK to Developer Environment.Oct 24 2016, 1:10 PM

sitter updated the task description. (Show Details)

I wrote a new magic script which uses appstream and the new stuff from T3926 to build a comprehensive list of frameworks as well as extenders of org.kde.development.

Unfortunately we can't build this as for supposedly existing reasons our tooling is not debian policy compatible and doesn't install build depends when building the source. @jriddell suggested adding the deps to the static list of packages staged into the docker images, but that also doesn't fly since that doesn't use neon archives http://build.neon.kde.org/job/mgmt_docker/label=master/1335/console
Maybe we can move the shebang to a different target, given we have a very lax network policy we can probably also do it at binary build stage.

Blocked for now.

what's needed for the kdede script to generate a package you can include in the repositories?

We now have a package, albeit using dependencies from a different script because the packages script for generic resolution falls over dead (and doesn't use our supremely fast api ;))

Some thoughts on the appdata thingy itself:

I think it shouldn't be addon type as addons aren't shown as apps in discover?
Needs an icon
Needs screenshots

Proper repo request for kde:kde-development-environment is also still pending.

In T3722#65169, @sitter wrote:

We now have a package, albeit using dependencies from a different script because the packages script for generic resolution falls over dead (and doesn't use our supremely fast api ;))

It shouldn't fail anymore, will get to your fancy api soon enough

Some thoughts on the appdata thingy itself:

I think it shouldn't be addon type as addons aren't shown as apps in discover?

Discover does display addons, AppStream does have some limitations on addons I need to get the hang of, though.

Needs an icon

True

Needs screenshots

Are you sure? what do you have in mind? Just show KDevelop?

Proper repo request for kde:kde-development-environment is also still pending.

Pending on sysadmin

I iterated the appstream file a bit.

In T3722#65229, @apol wrote:

In T3722#65169, @sitter wrote:

Needs screenshots

Are you sure? what do you have in mind? Just show KDevelop?

Plasma desktop with kdevelop open and a terminal maybe. Just needs to look nice, we don't really derive value from it beyond being flashy or whatever.

Plasma desktop with kdevelop open and a terminal maybe. Just needs to look nice, we don't really derive value from it beyond being flashy or whatever.

This will be more fun to do once we get to see the package in Discover.

Relevant related ticket in AppStream https://github.com/ximion/appstream/issues/87

Script works now and is wired up with packaging (currently fails to build on user edition for reasons). -dev list seems exhaustive now.

As an additional todo: the script currently doesn't resolve extenders of org.kde.development.desktop via appstream so it relies on the static list for applications.

@apol why do we pull in clang and gcc?

I think it's good to have the different compilers, we'll be pulling most of clang through most of the tooling (kdevelop, clazy, qtcreator,...).

In fact, I'd like to enable clazy eventually, although most distros don't package it yet.

I'm trying to get something like this working:

diff --git a/org.kde.development.appdata.xml b/org.kde.development.appdata.xml
index ca41a93..2ee8e51 100644
--- a/org.kde.development.appdata.xml
+++ b/org.kde.development.appdata.xml
@@ -21,6 +21,11 @@
         </screenshot>
     </screenshots>
 
+    <suggests>
+        <id>org.kde.kate.desktop</id>
+        <id>org.kde.kdevelop.desktop</id>
+    </suggests>
+
     <url type="help">https://techbase.kde.org/Development/Tutorials</url>
     <project_group>KDE</project_group>
 </component>

At the momement I get an appstream warning:

$ make check 
appstreamcli validate org.kde.development.appdata.xml
W - org.kde.development.appdata.xml:org.kde.development:24
    Found invalid tag: 'suggests'. Non-standard tags must be prefixed with "x-".