Okay, to spell it out, there are replacements for xntpd, xntpdc that 
have different names,
(ntpd, ntpdc) so they could coexist.

There are replacements for ntpdate, ntpq and ntptrace which have the 
same name, but
they are pretty much backwards compatible. This is something I will be 
looking at
more closely to see if there are any caveats.

There is a manifest and method to go with ntpd. The method is called 
xntp and the
manifest is ntp.xml. So, the methods could happily co-exist, but the 
manifest has
a problem. I suppose we could call the manifest ntp4.xml and the method ntp.
Unfortunately, SMF currently is happy accepting "ntp" when a FMRI is 
expected.
Since running ntpd and xntpd are mutually exclusive, it would certainly 
be nice
to have them both in a single manifest, but since we will be delivering 
ntpd into
the SFW consolidation and xntpd is in ON, this is problematic.

On the other hand, we might very well be able to replace all the current 
bits with
the new ones. The ntpd and xntpd daemons are very nearly compatible and 
accept
very nearly the same configuration options. Or I should say that ntpd is 
backwards
compatible with xntpd, except for the keywords that we added at Sun. 
Again, I
will be looking at the compatibility issues more closely.

But there still are the man pages for ntpdate, ntpq and ntptrace which 
are already installed.


James Carlson wrote:
> Brian Gupta writes:
>   
>> I would require all ntp related packages to be removed as a preinstall
>> action. My only concern would be backing up the config files. Are they
>> compatible between the two versions?
>>     
>
> Yuck.
>
> I'd just deliver the new files to a different location (or under a
> different name) so that there is no conflict.  You can then safely
> switch back and forth as needed without mucking with packages.
>
> Better still, non-conflicting packaging is one of the fundamental ARC
> requirements.  You don't need to be best-practice-compliant to post
> beta test code, but I'd suggest that it's a good idea just in the
> interest of avoiding unintended trouble.
>
>   


Reply via email to