Re: Removal from Slackware 12 ??

[Felipe Sanchez <izto@xxxxxxxxxxxxxxxxx>]

On Fri, 3 Aug 2007, Lawrence Toal wrote:

> Perhaps you've already seen it, but there is this thread:
>
> http://help.lockergnome.com/linux/Whats-problem-checkinstall-installwatch-ftopict472532.html
>
>
> > 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.


Felipe.