Naming of the tarball release: https://github.com/paulusmack/ppp/archive/ppp-2.5.1.tar.gz #519
Comments
|
@paulusmack: Can you look? |
|
I'm not impressed with github's release mechanisms. Besides this naming snafu, it also doesn't include things like the I recommend you get ppp-2.5.1.tar.gz from https://download.samba.org/pub/ppp/ and use that. |
|
Not to mention the .tar.gz at https://download.samba.org/pub/ppp/ppp-2.5.1.tar.gz is double-compressed: 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). 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:
I don't like either option. |
Whoops! Fixed now. |
|
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. |
|
It would not no. |
|
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). |
|
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. |
I would be interested to see that. |
This relates to ppp-project#519 and addresses the portion where "we can also exclude things like /.github/ from the release". Signed-off-by: Jaco Kroon <[email protected]>
|
@paulusmack please check if this will work for you: |
|
@Neustradamus do you mean we need to rename the existing tags? Note that my script does a little bit more than just tagging. The running of ./autogen.sh hasn't been tested either, but I cannot see that it shouldn't work. In short: it creates a tag, exports that tag (using git-archive), extracts, does the running of scripts (eg, autogen.sh but other mechanisms can be added too), and then re-compresses to the various release artifact options, before proceeding to create the release on github and uploading the artifacts. If there is no autogen.sh to be run this is extremely round-about and pointless and one could purely rely on the github release process. I suspect this may well be why many projects do commit ./configure into the repository (I disagree with this approach). For a second there I wondered about excluding the various .ac and .m4 files then I realised many distributions (Gentoo included) can and does apply patches and then re-bootstraps, so we should keep those). |
This relates to #519 and addresses the portion where "we can also exclude things like /.github/ from the release". Signed-off-by: Jaco Kroon <[email protected]>
|
It appears that both make dist-gzip and github are clever enough to strip off the 'v' from a tag name such as "v2.5.2". So I think that's the best name to use, not "2.5.2" or "ppp-2.5.2". @jkroonza your
For this release I went with |
|
@paulusmack PRs welcome to add a mechanism to sign the tag. You can exclude additional files by adding patterns to .gitattributes, eg Changes-* export-ignore, but looks like you added then to be included rather on the Makefile side. Yes, those files look that you mention (Makefile etc) are the result of ./configure, they should not be in the tarball I don't think. Perhaps rather than running ./autogen I should simply look for configure.ac and perform: autoreconf --install && autoreconf rather than executing any found autogen.sh script? The tarbal from github should be exactly what's in git, minus he export-ignore files in .gitattributes, + generated files by ./autogen.sh INSTALL on my system after autgen.sh is a symbolic link to /usr/share/automake-1.16/INSTALL, so too for the other files listed in that bullet, creating a dummy release of those I only have the INSTALL ad m4/* in the archive as symlinks: There are two fixes here: in autogen.sh drop the --symlink option on line 17. in release-script, add -h to tar. Or above. Your thoughts? |
Hey guys,
Using this URL:
When I extract this on the commandline, I get this directory:
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:
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".
The text was updated successfully, but these errors were encountered: