Reconciling Packaging Data (2)

Posted on

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!

7 Comment(s)

  1. Do you ever introduce yourself at KDE events by walking up to people and shouting “I am GROOT.!” ? 🙂 But seriously, thanks for all the hard work you put in, – it’s deeply appreciated.

    1. No. I haven’t seen that movie. For most people in KDE, I’m [ade] (Not Ade, that’s someone else in the Free Software world).

  2. For the “list of packages” you should know that the sysadmins are making a Web API that is meant to answer questions precisely like this. See https://community.kde.org/Sysadmin/Project_Metadata_API for more details.

    While the API call that I think should do what you want (https://apps.kde.org/api/v1/index/frameworks ) still gives a 500 error, and the multiple projects endpoint (https://apps.kde.org/api/v1/projects ) is still disabled, this appears to be the direction things are headed.

    The current canonical way of listing modules is actually from the kde_projects.xml file, not from kde-build-metadata.

    If you want a very simple listing of frameworks then probably the easiest thing you can do right now is to run “kdesrc-build -p –print-modules frameworks” (with kdesrc-build configured to use KF5, of course). Just make sure you don’t have any framework modules ignored with the “ignore-modules” option when you do this! At some point kdesrc-build will use the Web API (probably with lots of caching) but right now it reads the XML file.

    1. It’s great that there’s already some documentation on this! A big advantage of the Randa meetings is that I can shout out wild ideas and have them somewhat validated over breakfast, so I knew sysadmin was doing something in this direction. Today we had a UNIX packagers BoF and talked, among other things, how we can get metadata of all sorts out of the buildsystem, CI, and other KDE-centralized resources.

  3. Hi,

    You makes very interesting remarks about the metainfo.yaml files. As I’m the new maintainer of this (and of KApidox which it is made for) we might discuss about how to improve this. For instance we could add the webpage url in the metainfo. We already have irc channel, mailing list, so it wouldn’t be a problem.

    IMOH, putting all the metadata in the same place would be great, and would allow scripts to generate better the AppData metadata, to get a more comprehensive documentation of the API, and maybe help packagers? Any thoughts are welcome to go further, just ping me or contact me by email 😉

    Cheers

    1. It would be interesting to compare and contrast the appdata and the metainfo data formats. Ideally we’d be able to find the appdata easily in the source tarball, but I think we could live with retrieving them from the CI — after all, CI builds the stuff and installs the appdata files to sensible locations on the CI systems, so we could pull them more easily from there.

      1. Oops, my sentence was misleading.

        With “Putting all metadata in the same place” I meant putting all information about ONE library/app in the same place, that is it’s own repository. This will remove the need to keep various places up-to-date with tons of cross-scripts.

Comments are closed.