Developer Environment
Closed, ResolvedPublic

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
sitter created this task.Sep 13 2016, 1:13 PM
apol added a subscriber: mak.Sep 13 2016, 1:26 PM

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

mak added a comment.Sep 20 2016, 4:33 PM

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)
sitter added a subscriber: jriddell.Nov 8 2016, 1:22 PM

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.

apol added a comment.Nov 8 2016, 1:46 PM

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.

apol added a comment.Nov 9 2016, 3:33 PM
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

apol added a comment.Nov 9 2016, 4:01 PM

I iterated the appstream file a bit.

sitter added a comment.Nov 9 2016, 4:03 PM
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.

apol added a comment.Nov 9 2016, 4:12 PM

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?

apol added a comment.Nov 11 2016, 1:37 PM

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.

apol added a comment.Nov 11 2016, 1:46 PM

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-".
apol added a comment.Nov 14 2016, 2:00 PM

<suggests> now works, appstream was broken then fixed.

mak added a comment.Nov 14 2016, 5:21 PM

FTR, it always worked, it was just not validated properly ;-)

sitter moved this task from Doing to Review on the Neon board.EditedNov 24 2016, 1:22 PM

Announced to distro list.

Neon user edition has a build now, meaning it finally is also in user edition discover! (!user blocked by T2971) https://packaging.neon.kde.org/neon-packaging/kdesdk-devenv-dependencies.git/

@apol I still think the component needs an icon, looks a bit meh right now.

need to finalize neon ISO but I think that best becomes a new task

apol added a comment.Nov 24 2016, 3:31 PM

@sitter the icon is set as stock, so it should come from the icon theme.

apol added a comment.Nov 24 2016, 3:37 PM

Looks like it was a bug in Discover that wasn't taking stock icons into account. Fixed.
https://cgit.kde.org/discover.git/commit/?id=369ce7b623008753e8e65c7378fdc4be1fa870bc

apol added a comment.EditedNov 26 2016, 12:44 AM

Someone's onto us... http://xkcd.com/1764/

ISO doesn't build
E: Unable to locate package kde-development-environment

oh I see that's https://phabricator.kde.org/T4694
this one seems fine then, closing

jriddell closed this task as Resolved.Jan 24 2017, 5:10 PM

This should be done in a KDE repo though, even if only for translations