On 01/03/2020 02.28, Anuradha Weeraman wrote: > On Thu, Feb 06, 2020 at 03:44:51PM +0000, Thorsten Glaser wrote: >> I had considered that, but creating a ksh-common package for just >> one file, which in addition to that is a skeleton file that is not >> used during normal operation, just adduser, seems overkill. The >> sequence of installing both then removing one is also expected to >> occur only rarely, most users would either install one, or both, >> and then keep that. I had thought that that with the Replaces on >> the other packages would be sufficient. >> >> Is it possible to make an exception here, considering the file in >> question and that it is documented? > > Hi Andreas > > I would agree on Thorsten's point above that it would be somewhat > overkill in this given scenario. > > Please suggest if you would be okay with an exception in this regard, or > if you still feel that this needs to be addressed?
I'm not really happy with this, since it may result in some weird behavior (spurious disappearance of .kshrc looking non-deterministic) at some point in the future. Both ksh and ksh93 ship the same .kshrc. I assume, ksh93 will go away at some point in the future even if its alternative currently has higher priority. Would it be possible to have ksh93 depend on ksh? That might also help encourage migration from ksh93. Then only ksh ships .kshrc (with B+R: ksh93 (<< 93u+20120801-8~) to properly claim ownership of .kshrc again) while ksh93 either drops the unversioned R: ksh or makes it versioned to match the existing Breaks. Andreas
