So previously I looked at the dependency data available in KDE repositories, and how that translates to information in the FreeBSD packaging system (i.e. the ports Makefiles). It seems likely that judicious use of list_dependencies can help fill in the dependency information when depending on KDE and Qt components.

"Judicious" here means something like "after the Randa *NIX-deployment meeting tomorrow", since over lunch I learned from upstream (Scarlett) that the inconsistencies in the dependency data I noticed earlier are going to be tackled.

So it's good to be here in Randa at the cross-platform meeting, also for the *NIX packagers.

But let's look at two other bits of information in a FreeBSD port: the COMMENT string in the Makefile and the pkg-descr file.

KDE Frameworks all have a metainfo.yaml file, so there's 81 of those sitting on y hard drive right now. Each of those files has a description line that could be used to fill the COMMENT. Since this is the upstream short description of the software product, that seems like a good pithy thing to use instead of coming up with our own.

The pkg-descr is a larger file, with multiple lines of text allowed describing the package. One special line in the file starts with WWW:, followed by a space, followed by the URL of the package's homepage. That is information that isn't available in the metadata in Frameworks. It could be available in the AppStream data, except that none of the Frameworks seem to have that, while AppStream does support generic components.

So my plan is slowly congealing, like lime-Jell-O pudding, into the following:

  • Get kde-build-metadata, on the assumption that it contains a list of all the frameworks (in particular all those frameworks released in a given iteration on KDE Frameworks)
  • For each Framework listed there:
    • grab the released tarball, and extract the description from the metainfo.yaml.
    • if there's AppData somewhere, extract the description from it (that's probably XSLT).
    • get dependency information from the build-metadata.
    • read the existing port Makefile to get FreeBSD-metadata.
    • write a new pkg-descr and Makefile.
    • make distinfo and run some FreeBSD-preparatory scripts.

See, with one bit of tooling, we can lighten our maintainence burden and make our package descriptions more consistent with upstream. It's a win-win!