OK, I've got it. Let me think about this problem a little bit.

@rtsisyk What kind of issues do you mean? Could you please elaborate on that?

Let me explain the situation in more detail. For example, mysql has its own VERSION file (see https://github.com/mysql/mysql-server/blob/5.7/VERSION). packpack at the stage of tarball creating rewrites it, which leads to errors during futher compilation.

Quite frankly, I did not really understand where the contents of this file are later used, so I just changed its name in the patch.

Perhaps it makes sense to refuse to create this file at all, however, at the moment it breaks down the building of projects containing a file with that name in topdir.

Just curoius, why don't you file a ticket with them so that they remove it?-)

@kostja I guess that was a joke, but since the reporter may take it seriously and waste his time, no, filing it with MySQL won't work. Besides, I'm sure MySQL is not the only project having VERSION in the root dir.

@rtsisyk what does packpack use it for? I can't find it in the source too.

ping?

It seems it comes from b1765dd and also used to set PACKVERSION in ${REPO_ROOT}/packpack during packaging of packpack itself (see ${REPO_ROOT}/Makefile).

I think it make sense to skip VERSION file generation if it is already presented.

(Unlikely @kostja jokes, he was mysql developer in the past.)

I looked at the VERSION file from mysql. It is not a file with a version string: it uses its own format. We cannot use it here.

Regarding using of VERSION.packpack: it is quite expected behaviour to have a version file in a tarball, named exactly as VERSION. Packpack is used, in particular, for tarballs generation, so I would not change the file name.

It is strange to use one version for building and another one for a package name, but maybe we can keep a version file if it already exists for some reason. I'm still not sure it'll be good solution.

Any other thoughts?

As a raw idea: allow to pass your own version file name.