KDE Applications 16.04.0 packages available for packagers

[Ben Cooksley]

On Sat, Apr 16, 2016 at 3:20 AM, Eric Hameleers <alien at slackware.com> wrote:
> On Fri, 15 Apr 2016, Martin Graesslin wrote:
>
>>>>> Please understand this.
>>>>> As a distro packager, I would welcome a simple piece of documentation
>>>>> written by the developer that is *not* a CMakeLists.txt file.
>>>>
>>>>
>>>> At Plasma we are currently discussing a metadata format for our projects
>>>> including the inter-project dependencies. Please have a look at https://
>>>> mail.kde.org/pipermail/plasma-devel/2016-April/051581.html whether that
>>>> would help you.
>>>
>>>
>>> Inter-project dependencies need to be stored in a central repository.
>>> Otherwise it is *impossible* for scripts such as kdesrc-build as well
>>> as the CI system to resolve project dependencies (because you need to
>>> drag in dependencies of dependencies).
>>> This issue is actually more severe for kdesrc-build which needs to be
>>> able to resolve the dependency tree to determine the build order.
>>>
>>> Please consult with those of us who have worked on inter-project
>>> dependency stuff within KDE before when making proposals such as this.
>>
>>
>> Please note that this does not intend to replace the global dependency
>> data.
>> It's more intended to be of use for distributions. I completely understand
>> Eric's concerns and are trying to address exactly that.
>>
>> The main problem with the more global build data is that it's rolling. It
>> doesn't preserve the dependencies. E.g. if I would look at build metadata
>> for
>> KWin right now it would not match the dependencies of the Plasma 5.6
>> releases.
>>
>> As the metadata is bundled with the tarball it would be up to date.
>>
>> Cheers
>> Martin
>
>
> I understand that the CI tools need to be able to resolve interdependencies.
> So, why not use CI functionality to generate a global dependency list and
> publish that? It would be an essential first stop for everyone trying to
> compile KDE components.

If you clone the repository kde-build-metadata from git.kde.org you
will find in the tools folder a script called "list_dependencies".
Once given a branch group (usually kf5-qt5, but for Qt 4 based
software you'll want to use latest-qt4) and the name of the repository
it can spit out the complete list of projects a given tarball /
repository depends on.

Additional work would be needed to sort this into a build order, but
for those of you whose packaging systems just need to know what to
depend on, that should be quite helpful I think.

>
> But Martin's proposal is a sane one, too. If a project documents internally,
> in its own release tarballs, in an agreed-upon file format, which other KDE
> components it is relying on, that would be helpful indeed for distro
> packagers. The CI tools will probably only look at git head and not bother
> with releases (correct me if I am wrong). But the developer will have to
> keep a dependency list (obscure and not easily readable to human eyes) in
> CMakeLists anyway, so doing the same in a human-readable way is a bonus for
> us, humans.
>
> Cheers, Eric

Regards,
Ben

>
> --
> Eric Hameleers <alien at slackware.com>
> Home: http://alien.slackbook.org/blog/
> _______________________________________________
> release-team mailing list
> release-team at kde.org
> https://mail.kde.org/mailman/listinfo/release-team