I received replies from: ed.rolison@itc.alstom.com Gert-Jan Hagenaars [gj@hagenaars.com] Andrew J Caines [Andrew.J.Caines@wcom.com] Fabrice Guerini [fabrice@bluemartini.com] Matthew Stier [Matthew.Stier@fnc.fujitsu.com] jheiss@ofb.net (Jason) Ed and Matthew both identified the root cause of my problem (Jason was partially correct). In my original message I said my prototype file looks like this: i pkginfo f none /etc/init.d/informix=/etc/init.d/informix 0744 informix informix f none /etc/init.d/S94informix=/etc/rc2.d/S94informix 0744 informix informix In order for the S94informix file to be recognized as a hard link, the line should have looked like this: l none /etc/init.d/S94informix=/etc/init.d/informix 0744 informix informix In my original message I used the following command to add the line to the prototype file: pkgproto /etc/rc2.d/informix=/etc/rc2.d/informix >> prototype I incorrectly assumed that pkgproto could tell that the file was a hardlink and would create the appropriate entry in the prototype file. Matthew remarked, "pkgproto is capable of detecting hard links within a single run. However, your example has two runs of one file each." I tried this, and I believe Matthew is correct. The moral of the story is: Be carefull how you construct your prototype file when dealing with hard links. A few people commented that piping the output of a find command to the pkgproto command may be a "better" way to build the prototype file. In my experience, this is sometimes the case, but it is situational. In the end, all that matters is that the prototype file is set up correctly, and mine wasn't. Regarding one of my proposed work arounds, Ed said, "Creating links with a postinstall is not good, because then they won't be removed by pkgrm (and with a startup script, that can be messy)". I agree that you have to be careful here. If you want to take the plunge and do something in the postinstall script, it's probably a good idea to add corresponding logic to the preremove script. Several people had opionions about my P.S. regarding hard links vs. symbolic links to /etc/init.d/. The replies were interesting. I still can't tell whether one type of link is really better than the other. Again, I suppose it's situational. Here's what folks had to say: Ed wrote: I've also always used hardlinks in rcx.d but there are definitely a few symlinks in some of them. I guess this might just be a hangover frmo the way things were always done. Gert-Jan wrote: Just on a personal note: I've _always_ used soft links in /etc/rc2.d (and the rest). Simply because there's always a couple of newbie system administrators around, and I want to make sure that they know where the "real" scripts live. So my policy has always been: there are _only_ soft links in the rc*d directories, all the real stuff lives in /etc/init.d Andrew wrote: There are at least two common agruments against symlinks. The first is that they are a dirty hack created for linking across filesystems and that symlinking within a filesystem is symptomatic of ignorance. Since /etc must be in the root filesystem, there is no need for symlinks. The second is that that there is a performace penalty. A symlink is the equivalent of a sign on the door saying "No-one home. Try over there". This means that the number file tree traversals and other things is doubled and the various caches can't be properly or efficiently used. For startup, this isn't as big and issue as, for example, web content. Fabrice wrote: Well, IMHO, for what it's worth, Sun's decision to use hard links between /etc/rc*.d and /etc/init.d is a poor one. It makes it difficult for you to determine what each start-up file is linked to. In addition, it forces you to have the start-up file and its link on the same filesystem, which you may or may not want to do. Any time I create a new start-up file, I use symbolic links instead. This has the advantage, if I change, say, /etc/init.d/sendmail with an editor which does not conserve the inode (or by using the "cp" and "mv" commands), my link is still good, where with a hard link, I could make changes until I'm blue in the face and would wonder why they never seem to take effect at boot time. _______________________________________________ sunmanagers mailing list sunmanagers@sunmanagers.org http://www.sunmanagers.org/mailman/listinfo/sunmanagersReceived on Thu Mar 14 13:25:21 2002
This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:42:37 EST