[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Removal from Slackware 12 ??
- To: Lawrence Toal <let02do@xxxxxxx>
- Subject: Re: Removal from Slackware 12 ??
- From: Felipe Sanchez <izto@xxxxxxxxxxxxxxxxx>
- Date: Fri, 3 Aug 2007 15:32:34 -0500 (CDT)
- Cc: checkinstall-list <checkinstall-list@xxxxxxxxxxxxxxxxx>
- Delivered-to: mailing list checkinstall-list@xxxxxxxxxxxxxxxxx
- In-reply-to: <200708031340.07004.let02do@xxxxxxx>
- Mailing-list: contact checkinstall-list-help@xxxxxxxxxxxxxxxxx; run by ezmlm
- References: <200708022256.44902.let02do@xxxxxxx> <200708031340.07004.let02do@xxxxxxx>
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
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
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
YMMV, though. Please share your experiences.