On 01/09/2017 06:32 AM, Karel Zak wrote: > On Sat, Jan 07, 2017 at 11:06:23PM +0000, Sami Kerola wrote: >>>> >>>> >>>> I tried to convince Karel of this long ago. This code has been broken >>>> from day one, so nobody can be using it. IMO, it should be removed now. >>>> >>>> >> >> I agree. --compare is broken. I think there are couple options. >> >> 1) remove --compare code, and mention in manual page it's gone >> 2) keep the code, but deprecate it >> 3) keep the code, and fix it (but how???) >> 4) keep the broken code and whistle happy days theme song >> 5) something else >> >> I am 60-40 leaning towards recommending removal. If we don't remove rest >> of my 40 goes to deprecate. Karel, I think we need maintainer advice. > > I have re-read our old discussions about this topic and I agree that > it's better to kill the problematic (broken?) functionality that care > about backward compatibility. It really seems nobody uses this stuff. > > So, go ahead and send patch to remove all around --compare. > > BTW, we had discussion about unmaintained adjtimex merge to > util-linux. > > Karel > > It is true, I suggested picking up the orphaned adjtimex(8) code as an alternative to inserting it's functionality into hwclock(8). However, I have since learned that the useful functions of adjtimex(8) are available via the ntp utilities. The rest of its (dis)abilities have the same problems we are seeing when reimplementing them into hwclock(8). I think perhaps there were good reasons adjtimex(8) was abandoned. Before, I believed adjtimex(8) might be a good fit for util-linux, now I am not so sure. If someone demonstrates a useful purpose for it I will change my position. -- To unsubscribe from this list: send the line "unsubscribe util-linux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
