Opened 10 months ago
Closed 5 weeks ago
#1740 closed enhancement (fixed)
Warn about tarball name vs. extracted directory name mismatch
Reported by: | xry111 | Owned by: | Pierre Labastie |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | jhalfs | Version: | GIT |
Severity: | normal | Keywords: | |
Cc: |
Description
Now we have a "vim-9.1.0405.tar.gz" on anduin but it's actually a vim-9.1.0330 release tarball and extracts into vim-9.1.0330.
If jhalfs could warn about such a mismatch, it might be easier to catch the issue.
Change History (8)
comment:1 by , 10 months ago
comment:2 by , 7 weeks ago
We could try to catch such mismatches when running the scriptlet, because we extract the variable PKGDIR from the tarball (tar -t), and we have VERSION from the version entity in the book (through sect1info), so that we could add a test like:
if [ ${PKGDIR%$VERSION} = $PKGDIR ]; then <exit on error>; fi
But the risk of false positives (versions of the form xx.yy.zz and directory of the form package-xxyyzz for example) is much greater than the risk of mismatches, since now the only things that are hosted on anduin are the systemd manual pages and udev-lfs. But for those, the mismatch would be immediately apparent because the instructions in the book would immediately fail.
So I'm inclined to close as wontfix. But leaving open now for discussion...
comment:3 by , 7 weeks ago
Maybe it should be "warn about tarball name vs. extracted directory name mismatch undocumented by the book." I.e. in the book we already have notes like "The tarball extracts into the smartypants.py-2.0.1 directory." and maybe we can use
<filename class='directory' role='extract-dir'>smartypants.py-&smartypants-version;</filename>
in the note to indicate jhalfs the mismatch is known.
comment:4 by , 7 weeks ago
Owner: | changed from | to
---|---|
Status: | new → accepted |
Note that with the test I propose, any directory name that ends with $VERSION as known by the <productversion> element would be considered good. That is, the samrtypants exammple above would pass the test. That wouldn't catch errors like vim-x.y extracting to gcc-x.y (but this is really a corner case, I guess). I'll test which packages don't pass the test, maybe not so many...
comment:5 by , 6 weeks ago
Ok, all packages pass the test... But not sure where to put it.:
Presently, I have it in function get_sources, which allows failing early in case of mismatch. But it is only run if the user asks for downloading the sources. Note that if the user does not ask for downloading the source, there is no way to test early, because the user may as well download the source after running the jhalfs preparation.
The other possible place for the test is in the scriptlet, but then, if the test does not pass, the failure would occur very late, when the scriptlet is run during the build.
comment:6 by , 6 weeks ago
You can try branch plabs/check-version. But I am not sure where to find a faulty tarball for real tests...
comment:7 by , 6 weeks ago
Using LFS book at commit 760d28c809, and having expat-2.6.2 in /sources (it cannot be found anymore on the server), I could verify that the downloads stop at vim-9.1.0405 because of the version mismatch. So branch plabs/check-version allows catching the problem provided the user asks to retrieve the sources. But note that it is enough to have the sources in $SRC_ARCHIVE: no real download is needed.
Main problem is that tarball names and extracted directory names do not always match anyway. Maybe the script for the porg package manager could be used to extract versions and compare them.