A more machine readable and "machine actionable" Changes

[sedusedan]

Not strictly related to Perl, because I want this to be useful outside the Perl toolchain too, but here it goes...

We already have the Changes file with its CPAN::Changes::Spec format standard (which I'm also using outside of Perl/CPAN distributions). What I'm trying to develop is something more machine readable and "machine actionable", for example:

1. The nature of the release (bug fixes only, new features, removed features, whether there are API incompatibilities, security update). If there is an API incompatibility or removed feature, I would like the installer (like cpanminus) to show the detail of the change first and ask for user's confirmation.
2. What services/daemons should be restarted.
3. What things need to be done after an upgrade/install (e.g. what config variables need/recommended to be set). This can be just a note and displayed for the user.
4. There will be others, but so far those (#1, #2, #3) are the ones that are immediately needed in my project.

One way to do this is to define more detailed specialized specification to the Changes entry, some of which have already been seen in practice. For example, if there is a group/heading called INCOMPATIBLE CHANGES, it means there are incompatible changes and the installer should confirm first. Likewise for #2, for example, we can define a group/heading called RESTARTED SERVICES or SERVICES TO RESTART (though this is arguably a misuse of the Changes file).

I am also aware that OS packages (like Debian's .deb, Redhat's RPM) deal with these installation/upgrade issues.

Any pointers/thoughts? I'd like to keep things simple and tend to just encode the required metadata/information into Changes, but I also don't want to end up with an overloaded and strange-looking Changes.

[tobyink]

I describe my distribution changes in RDF, and then use that RDF to generate the human-readable Changes files.

What is RDF?

Despite rumours you might have heard to the contrary, RDF is not "based on XML", though it can be serialized as XML. Apparently Mark Pilgrim once mentioned that his partner had an XML file listing her shoe collection, but that this did not imply that her shoes were based on XML. :-)

RDF is an abstract data model which can be serialized in a variety of formats. It's a directed graph where edges are labelled with URIs, and nodes may either represent things (called "resources" in RDF terminology) or literal values (strings, numbers, dates, etc). Resources may also be labelled with a URI, but do not have to be.

Excuse my ASCII-art. The ( ) bits are supposed to be blank nodes (i.e. resources without a URI).

        
 ( ) ---[http://usefulinc.com/ns/doap#name]---> "Type-Tiny"
  |
  |
 [http://usefulinc.com/ns/doap#release]
  |
  |
  V   
 ( ) ---[http://usefulinc.com/ns/doap#revision]---> "0.044"

But because drawing ASCII art can be tedious, we've come up with better ways to write down RDF. Here's the same data represented using Turtle:

@prefix doap: <http://usefulinc.com/ns/doap#>.

:x  doap:name      "Type-Tiny".
:x  doap:release   :y.
:y  doap:revision  "0.044".

Or even:

@prefix doap: <http://usefulinc.com/ns/doap#>.

[] doap:name "Type-Tiny";
   doap:release [ doap:revision "0.044" ].

RDF for Perl Projects

For each of my distributions, I include various RDF data such as the project name, contributors, repository, bug tracker, etc, using DOAP. DOAP is an RDF vocabulary which is used by Mozilla, the Python Package Index, and others.

I also use a few of my own extensions to DOAP for dealing with dependency data, changelogs, bug reports, etc.

Then, when I package the distribution, not only do I bundle the RDF data (example for Type-Tiny 0.044), I also use it to generate many of the standard distribution files (META.yml, Changes, CREDITS, etc).

How is all this relevant...?

My changeset extension for DOAP allows you to classify each change with one or more URIs. For example http://ontologi.es/doap-changeset#BackCompat or http://ontologi.es/doap-changeset#SecurityFix, but you can create your own URIs too, if these classes are not sufficient.

RDF is very, very extensible. That's kind of the main point of it. It's a data model for creating a web-scale database.

[Anonymous Monk]

.ini CPAN::Changes - Read and write Changes files
.ini Module::Metadata::Changes - Manage a module's machine-readable Changes/CHANGES file
yaml Module::Changes - Machine-readable Changes file

CPAN::Changes Kwalitee Service

[DrHyde]

If I wanted to automagically restart services after installing, then the first thing I'd try would be writing a Module::Build subclass that would do it for me.