KDE Applications 16.04.0 packages available for packagers

[Eric Hameleers]

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.

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

-- 
Eric Hameleers <alien at slackware.com>
Home: http://alien.slackbook.org/blog/