tarball naming conventions about neoleo HOT 4 CLOSED

I'm not sure there's a better way of handling it, or much I can do. v8.0.0.zip and v8.0.0.tar.gz are actually generated automatically by github when a tag is created. I don't think there's a way of renaming them.

neoleo-8.0.tar.gz is a file generated by GNU autotools using make dist, and manually uploaded by me. This is actually the "important one". It contains, for example, the configure script. it's the one people should be downloading, particularly distro packagers, in order to create a package. It's the file that is incorporated into the Arch AUR repo (https://aur.archlinux.org/packages/neoleo/).

The ones labelled "source" are archives of the git repo, and is not the one people should be using. It would probably be less confusing if I was able to suppress the "source" archives, but it's part of how github works. Furthermore, it doesn't have the concept of "this is how GNU autools packages should be created", which is why I have to upload them manually.

from neoleo.

So if the sources' tarball can't be renamed, how about renaming the release tarballs to something of the form neoleo-release.x.y.x.tar.gz or neoleo-dist.x.y.x.tar.gz ?

Wait a minute. You can't possibly be the first person to be confronted with this issue. There have got to be a zillion (>1) projects on github using the GNU toolchain and issuing releases. Maybe ask github support for a pointer, or ask how to search for such repos in order to see how they handle this.

from neoleo.

So if the sources' tarball can't be renamed, how about renaming the release tarballs to something of the form neoleo-release.x.y.x.tar.gz or neoleo-dist.x.y.x.tar.gz ?

I guess that could be done. Running make dist actually creates the release tarball. It puts it in the form neoleo-x.y.z.tar.gz automatically. Then, running make distcheck makes sure that everything is packaged properly. I've found it takes a few attempts before I get it right.

Also, note that something like neoleo-x.y.z.tar.gz is the standard naming convention.

If had my way, I'd do away with the source archives, as it is obviously a source of confusion. If people really wanted to see the tagged version, then they could clone the repo and select the tag.

Wait a minute. You can't possibly be the first person to be confronted with this issue. There have got to be a zillion (>1) projects on github using the GNU toolchain and issuing releases. Maybe ask github support for a pointer, or ask how to search for such repos in order to see how they handle this.

I could investigate further. But remember, what's in the release tarball contains stuff that is built by autotools (the configure script being the prime example). Github wouldn't necessarily know that make dist is the way to build the release tarball. Github knows what's committed to the repo, it doesn't necessarily know about autotools.

from neoleo.

A new version has just been released. I have decided to exclude GNU tarballs. Just use the tarball instead. It means doing an extra "autoreconf -iv", but it's no real biggie.

So I'll close this issue.

from neoleo.