Comment 5 for bug 1602258

I've been meaning to post here on a status update on this, but I keep forgetting...

Anyway, at the Snap sprint in October, we discussed this again, this time delving a bit more into the details.

The plan is still the same as comment #2 indicates.

I have taken the first steps towards RPM support by adding support for using individual RPMs as sources[1], mimicking the support for using individual DEBs as sources. This will roll out with Snapcraft 2.22.

The next step will be to refactor the {build,stage}-packages to have apt/Ubuntu code split out into its own module, set up in a way that it implements a generic distro backend class. The class-oriented structure will make it easy to add other backends. Once this is in place, we will start implementing a backend using python3-dnf (part of dnf[2]), as it's more high level and stable than libdnf at the moment.

As for the snapcraft.yaml, we were leaning towards using the "for" keyword to indicate the distribution base, but I'm starting to think that maybe "use" or "using" might be better keywords, as it clearly indicates the expected relationship. We aren't completely certain yet of how we will indicate the release version (for example, Fedora 25, Mageia 6, openSUSE 42.2, etc.), as apparently "series" is special and we might need a different way to represent this. The current thought is to express it as a list (e.g. use: ["fedora", 25]) or a key-value map (e.g. use: [dist: "mageia", rel: 6]). Again, though, we're not quite at the point where we are able to start quibbling about the exact syntax.

However, we *are* making progress!

[1]: https://bugs.launchpad.net/snapcraft/+bug/1640296
[2]: https://github.com/rpm-software-management/dnf