[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Removal from Slackware 12 ??

On Fri, 3 Aug 2007, Lawrence Toal wrote:

Perhaps you've already seen it, but there is this thread:


I distinctly recall (but not sure from where: here, several years ago?)
that the problem with checkinstall is that it assumes a newer version
of tar than than (er) used by default in Slackware.

E.g. "grep tar /sbin/installpkg" returns the line

echo "WARNING: pkgtools are unstable with tar > 1.13."

Slack 11 used tar-1.13, Slack 12 uses tar-1.16.1.  Makes me want to
tinker a bit myself,  but here Slack 12 lives on a box whose video card
died.  :-(  Oh, well--its Ebay time again....

Actually yes, I've read the referenced thread before. At first I didn't now what did Stuart mean when he talks about the "at-style functions that glibc 2.5 is providing". I do know now, keep on reading :-)

As for the tar issue, it is indeed an old one. Even Slackware's pkgtools package don't use the newer tar, they use "tar-1.13" instead which is, oddly enough, included in the tar-1.16-1-i486-1 package installed by Slackware 12 (I just checked it).

For a long time now checkinstall has tested for the presence of tar-1.13 in the system and automatically uses it if available, so this shouldn't be an issue.

I just installed a Slack 12 box, downloaded, compiled and installed checkinstall-1.6.1 and it correctly built a package of itself.

When I did the chmod test suggested in the same thread I got a "/usr/test.txt: no such file or dir" message. When doing the same test with --fstrans=no it all worked fine.

The test was this:

checkinstall "echo hello > /usr/test.txt && chmod a+w /usr/test.txt &&
chown nobody /usr/test.txt"

At first I guessed that there was not really a new issue here. Only that the Slackware crowd finally got bitten by the old fstrans bug. (Which should have been fixed with the getcwd patch added in 1.6.1).

However, after following the chmod call with strace I finally found out what all the fuzz was about:

fchmodat (AT_FDCWD, "/usr/test.txt", 0666) = -1 ENOENT (No such file or directory)

After a quick lookup of fchmodat() I found out that in linux-2.6.16 a whole bunch of "relative path" function calls where introduced which installwatch knows nothing about:

(From the openat(2) manpage)

faccessat(2), fchmodat(2), fchownat(2), fstatat(2), futimesat(2), linkat(2), mkdirat(2), mknodat(2), open(2), path_resolution(2), readlinkat(2), renameat(2), symlinkat(2), unlinkat(2), mkfifoat(3).

Now there's enough for some late night patching fun  ;-)

I'll work on it and keep you posted.

The workaround for checkinstall-1.6.1 is to disable filesystem translation with --fstrans=no. This time however, it is not due to a fstrans bug. It just happens to be that by disabling fstrans then any not-installwatch-catched system call will have no problem finding the files where it expects them to be.

The rest of the file operations should also work because they are done to the files in the live system *before* they are copied to the package being built.

YMMV, though. Please share your experiences.