On Fri, Oct 23 2009, Bernd Eckenfels wrote: > In article <87r5sudn0p.fsf...@anzu.internal.golden-gryphon.com> you wrote: >> [ "$(stat -c %d/%i /sbin/init)" = "$(stat -Lc %d/%i /proc/1/exe >> 2>/dev/null)" ] ; then >> # So, init exists, and there is a linuxy /proc, and the inode of >> # the executable of the process with uid 1 is the same as >> # /sbin/init (ok, no init=/bin/sh going on) > > Maybe another check besides inode idendity is better, otherwise it will not > be able to be used afer an upgrade (and before reboot), or?
Not needed. If init has been just upgraded, it has been already told to init -u itself. So, what are the cases? Consider the events: I1 Init unpacked I2 my package unpacked C1 Init configured C2 my package configured These work A) I1 I2 C1 C2 B) I1 I2 C2 C1 C) I2 I1 C1 C2 D) I2 I1 C2 C1 E) I1 C1 I2 C2 F) I2 C2 I1 C1 What failure modes do you see that I need to clutter up my postinst to accommodate? > And for the "else" case a diagnostics message would be good. Umm, this is opportunistic: I don't think people want tob e bothered when running qemubuilder or doing things in a chroot. I am nto sure the information is valuable enough to clutter up the user interface; I am willing to hear reasons why I am wrong. manoj -- "But this one goes to eleven." Nigel Tufnel Manoj Srivastava <sriva...@debian.org> <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org