Snapcraft's version from debian/changelog

snapcraft
1

Following the recent addition of ‘version: git’ support, i was wondering if there was enough interest for a similar feature that, this time, would distill the version field from debian/changelog.

Since support for a dynamic version string is already present, i’m following those footsteps byt adding a single method that:

  1. regenerate debian/changelog (fdr clean)

  2. read the first line of debian/changelog

  3. applies the following regexep to the line read:

     m = re.search(
     r'^(?P<pkg>[a-zA-Z0-9\s.+-]+\({1})'
     r'(?P<version>[a-zA-Z0-9.-]+[~a-zA-Z0-9]*)'
     r'(?P<leftover>\){1}.+)$',
     output)

If any of the above condition fails or version is empty, i throw out an error and exit.

Comments?

2

Thanks @ppisati

So, this would work only for projects that have both the deb and snap packaging in the same repo, right?

If there is no debian directory, it would just fail?

3

Yes, this would only work for projects that are already packaged as a .deb but want to carry a snapcraft.yaml too - and if the debian/changelog file is not present there, or the release is not closed properly, parsing will fail and no snap package will be generated.

My natural target is the ubuntu kernel: at the moment we package it as a .deb and we ship a snapcraft.yaml in it but the version had to be manually kept in sync between the two worlds, this feature will make sure the generated kernel snap will always carry the same version as the .deb kernel.

4

I don’t like to have a lot of magic values for version, but now that we opened that door this propposal sounds reasonable to me. +1

@sergiusens?

5

Instead of a hand-crafted regex, maybe you could use dpkg-parsechangelog -c 1 -S Version ?

6

I’m not against it but then we are adding a dependency on ‘dpkg-parsechangelog’ - if there isn’t a strong reason to use an external tool, i would prefer something in-house.

1 Like
7

There’s a tentative patch for this feature available here and waiting for comments:

https://github.com/snapcore/snapcraft/pull/1313

8

The basic idea sounds sane, but that’s generating the changelog, isn’t it? That’s surprising and unwanted, I believe. As a proposed invariant for such features, nothing should be written as a consequence of reading the version of the project.

Another proposed invariant: the same source code should not yield two different versions depending solely on the user machine. As it is, the logic there seems to make choices while calculating the version that depend on the availability of certain tools. This will most likely create the potential for the exact same source having different versions on different machines, which seems bogus. If the source is the same, the version needs to be the same.

9

this code calls “fakeroot debian/rules clean” … there are lots of packages in the archive that will generate stuff in the clean phase using scripts and tools from build-deps (this is most awful behaviour but sadly very common)… for these packages you need to have the build deps installed before running “fakeroot debian/rules clean” else the command will fail…