Naming of the tarball release: https://github.com/paulusmack/ppp/archive/ppp-2.5.1.tar.gz

[rubyFeedback]

Hey guys,

Using this URL:

https://github.com/paulusmack/ppp/archive/ppp-2.5.1.tar.gz

When I extract this on the commandline, I get this directory:

ppp-ppp-2.5.1

So the ppp appears twice.

I believe the more natural name would be to use the same name as by the URL,
in other words:

ppp-2.5.1

Most other projects also do this. I assume some script may be automatically
renaming things, because a human being will probably rarely prepend a
'ppp-'. It also simplifies downstream scripts if the simple rule "basename of
the remote URL is the directory name when distracted".

[Neustradamus]

@paulusmack: Can you look?

[paulusmack]

I'm not impressed with github's release mechanisms. Besides this naming snafu, it also doesn't include things like the ./configure script which aren't checked in to git, but get generated by autogen.sh.

I recommend you get ppp-2.5.1.tar.gz from https://download.samba.org/pub/ppp/ and use that.

[jkroonza]

Not to mention the .tar.gz at https://download.samba.org/pub/ppp/ppp-2.5.1.tar.gz is double-compressed:

jkroon@plastiekpoot ~ $ wget https://download.samba.org/pub/ppp/ppp-2.5.1.tar.gz
--2024-09-19 11:49:33--  https://download.samba.org/pub/ppp/ppp-2.5.1.tar.gz
Resolving download.samba.org... 2a01:4f8:192:486::2:3, 144.76.82.148
Connecting to download.samba.org|2a01:4f8:192:486::2:3|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 994693 (971K) [application/gzip]
Saving to: ‘ppp-2.5.1.tar.gz’

ppp-2.5.1.tar.gz         100%[==================================>] 971.38K   173KB/s    in 5.6s    

2024-09-19 11:49:40 (173 KB/s) - ‘ppp-2.5.1.tar.gz’ saved [994693/994693]

jkroon@plastiekpoot ~ $ file ppp-2.5.1.tar.gz 
ppp-2.5.1.tar.gz: gzip compressed data, max compression, from Unix, original size modulo 2^32 995838
jkroon@plastiekpoot ~ $ gunzip < ppp-2.5.1.tar.gz | file -
/dev/stdin: gzip compressed data, from Unix
jkroon@plastiekpoot ~ $ gunzip < ppp-2.5.1.tar.gz | gunzip | file -
/dev/stdin: POSIX tar archive (GNU)

That said, I've never experienced the problems you describe above.

https://github.com/ppp-project/ppp/archive/refs/tags/ppp-2.5.1.tar.gz is not double-compressed, but it has the double path issue, so github does a ${package_name}-${tag}.tar.gz and files are in ${package_name}-${tag}. Since the tag includes ppp that causes the double path issue.

Then, I suspect we can also exclude things like /.github/ from the release (this can seemingly be done with .gitattributes).

https://softwareengineering.stackexchange.com/questions/366771/how-do-we-avoid-development-files-in-the-release

Does give a few pointers, but in short: Doesn't look like github release download, which really just downloads the git code as at a point, is going to work for ppp project, and come to think of it I find it more and more strange that I've not run into this crap elsewhere.

The only way to include ./configure (and any others) into the release archive for those generated downloads, is likely going to be to do one of:

1. Commit them into the repository (I don't like this).
2. Create the release, download the github one, extract, generate, archive, add as release artifact.

I don't like either option.

[paulusmack]

Not to mention the .tar.gz at https://download.samba.org/pub/ppp/ppp-2.5.1.tar.gz is double-compressed:

Whoops! Fixed now.

[paulusmack]

I could create a tag called '2.5.1' easily enough, and maybe redo the github release. That wouldn't fix the missing configure script, though.

[jkroonza]

It would not no.

[paulusmack]

Unless anyone can see a way to get the github release to include the configure script, I don't think there is anything to do here (except maybe to remember to create a tag called '2.5.2' next time).

[jkroonza]

@paulusmack

For what it's worth, I concur.

I'm not aware of a way to include that into the archive created by github. As such, I suggest:

tag as '2.5.2' rather than 2.5.1

Perform required to create the "not in git files" and remove "git only files", and create archive from that.

Attach to the release as release artifact.

Might be a good thing to script most of that perhaps, so that after the tag has been created you can simply do scripts/create_release_archive (or similar) which will then download the tag archive (which should exclude files tagged with export-ignore by way of .gitattributes), extract, create configure files (run autogen.sh) ... and then recompress that, ready to be attached to the release.

I'm happy to take a shot at such a script for you if you so desire. Done similar things before, just never integration into the gh cli tools to actually make and upload the releases, but happy to mess with that. Would potentially enable you just running ./make_release 2.5.2 which would do everything required for you (including creating the tags and releases potentially). Capacity is better at the moment, but still not abundant.

[paulusmack]

I'm happy to take a shot at such a script for you if you so desire. Done similar things before, just never integration into the gh cli tools to actually make and upload the releases, but happy to mess with that. Would potentially enable you just running ./make_release 2.5.2 which would do everything required for you (including creating the tags and releases potentially). Capacity is better at the moment, but still not abundant.

I would be interested to see that.