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 Pierre Labastie, 10 months ago

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.

comment:2 by Pierre Labastie, 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 xry111, 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 Pierre Labastie, 7 weeks ago

Owner: changed from alfs-log@… to Pierre Labastie
Status: newaccepted

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 Pierre Labastie, 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 Pierre Labastie, 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 Pierre Labastie, 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.

comment:8 by Pierre Labastie, 5 weeks ago

Resolution: fixed
Status: acceptedclosed

Fixed at 3006751e09

Note: See TracTickets for help on using tickets.