Felipe Sateler wrote: > El 28/07/08 02:48 LUK ShunTim escribió: >> Package: checkinstall >> Version: 1.6.1-8 >> Severity: grave >> Justification: causes non-serious data loss > > I'm not really sure if this is a grave bug... we'll leave it like this for > now.
Yes, I hesitated a bit when I set it. You definitely know the working of the code much better to decide. > >> I guess this is result of filesystem translation not working properly with >> the newer kernels as reported previously. >> >> When checkinstall is doing "Compressing man pages", it messes up the real >> man pages in /usr/share/man etc by re-compressing all man pages files >> (harmless, though) and rendering symbolic links to just an invalid .gz >> link. :-( Note: TRANSLATE=0 set and checkinstall invoked with root >> previlege. > > Then it shouldn't be the filesystem translation code. Yes, it shouldn't. Perhaps I did not put it clear enough. My concern is the safe behaviour of checkinstall -- during the packaging stage, it should not actually change the filesystem. I don't know if I'm correct in my understanding. No filesystem translation means (sudo) checkinstall *actually* writes files in /usr/bin, /usr/share, etc in the filesystem (not really safe as existing files may be overwritten/changed) while with file translation it does this in a temporary location, simulating the changes and is hence safe. > >> A possible work around is to disable compressing man pages by setting >> COMPRESS_MAN=0. But it appears that files left by checkinstall in >> /usr/share/man etc are not cleaned up for the case when INSTALL=0 is set. > > Could you provide a more complete description of the problem, please? > Hopefully with a test case. From what I gather: > > - Calling checkinstall without filesystem translation causes manpages to > doubly compress, which breaks them. > > Which manpages? Package was already installed? Please post a full > checkinstall > log with debug enabled. I discovered the problem when I saw compressing man pages takes a lot of time but unfortunately I cannot reproduce this problem behaviour any more. :-( I use sid and regularly updates stuff. It may be some unfortunate combinations of events. I've now set debug level to 2 in the config file and if I found similar happenings in the future, I'll send in the log. Will sending in the log file be enough? > > > > Saludos, > Felipe Sateler Thanks very much for answering and looking into it, ST -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
