<div> </div><div> </div><div></div><br><pre>On 2008-12-10，"Steve Young" <chemadm@hamilton.edu> wrote：
>Ahh.. I guess I mis-understood I was under the impression this
>"onceihave"??? was getting an rpm version of torque from somewhere. If
>he's building it himself then why not just modify the rpm to suit his
>own needs... Ok Garrick I gotcha.. put me down on your side =). Sorry
>for the confusion.. my bad.
><br><br>Yeah. I downloaded Torque tarball and compiled rpms with my preferred <br>options and configurations. Why I opened this thread is that I like<br>daemons can be stopped as other software, in default spec file :-)<br><br>Thanks.<br><br>Steven Wang<br><br> >-Steve
>
>
>
>On Dec 9, 2008, at 4:39 PM, Garrick Staples wrote:
>
>> On Tue, Dec 09, 2008 at 04:32:39PM -0500, Steve Young alleged:
>>> No I don't use rpm versions of torque server because too many times
>>> you get all sorts of dependancy problems. I'd rather compile it
>>> against the libs I currently have installed on the server.
>>
>> Again, we are talking about rpms that you are building. You can not
>> build rpms
>> against libs that aren't on your own machine.
>>
>>
>>> I do expect that for rpm packages (that I do use), when I tell it to
>>> remove the package that it actually does stop the daemon and remove
>>> the package. That seems to be the way most rpm's work. I would be a
>>> little confused to remove the rpm and find that afterwards there is
>>> still the daemon running? I could see using an rpm package for the
>>> client nodes (pbs_mom). There I would still expect that a uninstall
>>> would stop the daemon and then remove the package.
>>
>> How about a compromise? How about printing a warning message?
>>
>>
>>> For me, It's much easier to compile the app and when I need to make
>>> changes/upgrades I can compile another version and a quick stop of
>>> the
>>> daemon and start of the new daemon will get me running. If there are
>>> problems I can quickly revert back to the previous version. Suppose I
>>> remove the rpm package and try to install a new version only to find
>>> out that because of dependancies that I can't install the new
>>> version.
>>> Now I'm stuck and I hope I can re-install the old version of the
>>> package and get everything configured back the way I had it. This is
>>> why I don't like to use rpm's for certain server applications.
>>
>> Again, you *are* compiling the app. CRI doesn't distribute binary
>> rpms.
>>
>> And that stuff about deps is silly. Rpms are upgraded with 'rpm -U'
>> which does
>> the uninstall of the old package *after* installing the new
>> package. You can't
>> remove a package because you don't have the deps for the new package.
>>
>> Of course, you are free to use whatever you want. I'm not actually
>> saying that
>> you should be using rpms. I would just hate for you to make that
>> decision with
>> bad information!
>>
>>
>>> I do understand your point Garrick, and I agree with you about
>>> torque. It can be a tricky beast sometimes. I'm just pointing out
>>> that
>>> as an Admin I would actually expect that an rpm package would stop
>>> the
>>> daemon and remove it. Why would anyone not want it removed if that's
>>> what they asked for?
>>
>> Well, there are 2 possible scenerios.
>>
>> *shrug*
>>
>> --
>> Garrick Staples, GNU/Linux HPCC SysAdmin
>> University of Southern California
>>
>> See the Dishonor Roll at http://www.californiansagainsthate.com/
>>
>> _______________________________________________
>> torqueusers mailing list
>> torqueusers@supercluster.org
>> http://www.supercluster.org/mailman/listinfo/torqueusers
>
>_______________________________________________
>torqueusers mailing list
>torqueusers@supercluster.org
>http://www.supercluster.org/mailman/listinfo/torqueusers
</pre><br><!-- footer --><br>
<hr>
<font style="font-size:12px;line-height:15px;">[广告] </font><font style="font-size:12px;line-height:15px;"></font><a style="font-size:12px;line-height:15px; color:blue; text-decoration:underline;" href="http://popme.163.com/link/003985_1010_7027.html">2008年最受关注楼盘</a>