Re: What to do about RCS/OpenRCS

Hi;

On 08/05/2015 10:44 a.m., John Baldwin wrote:
> On Thursday, May 07, 2015 04:18:38 PM NGie Cooper wrote:
>> On Thu, May 7, 2015 at 1:38 PM, Pedro Giffuni <pfg_at_freebsd.org> wrote:
>>> Hello;
>>>
>>> On 05/07/15 14:56, Lyndon Nerenberg wrote:
>>>> On Thu, 7 May 2015, Pedro Giffuni wrote:
>>>>
>>>>> Unfortunately I don't use RCS enough (it looks like I should though) so
>>>>> I am not in a good position to take the next step and deal with any
>>>>> fallout it may produce.
>>>>
>>>> If we can have a build-knob to disable GNU RCS and enable the new one I
>>>> will happily twist up the new version and hammer on it.
>>>>
>>> Yes, that's usually the next step in the process. It is a little bit messy
>>> because
>>> there is a WITHOUT_RCS option and openrcs doesn't have rcsfreeze (and
>>> perhaps something else that we don't use).
>>>
>>> I really want to check out first if there is some strong opinion against
>>> OpenRCS. Perhaps someone that has used it before and thinks it is a
>>> bad idea.
>>>
>>> It looks like there are voices against it, so those have to be addressed
>>> first.
>> Setting WITHOUT_RCS also breaks etcupdate (the tool requires rcs
>> bits); check with jhb first to make sure that OpenRCS works with
>> etcupdate.
>> Cheers!
> I think this can be fixed by using diff3 instead of merge, I just haven't
> sat down and figured out the correct incantation.
>
> That said, I think that having a not-quite-working rcs (OpenRCS) in base
> is worse than having no rcs.  If OpenRCS is improved as per Xin's notes
> then just switching over is probably the path of least resistance.

To be honest, I just want to have options, and unfortunately OpenRCS is 
not one
at this time.

> I guess I see the following options:
>
>    1) Just leave GNU RCS in the tree.
>
>    2) Improve OpenRCS so it can be swapped in.
>
>    3) Remove RCS dependencies from other parts of the tree (e.g. etcupdate)
>       and import just a /bin/ident binary (perhaps from OpenRCS).
>
> Both 2) and 3) require some work.  I suspect 3) requires less. :)

I honestly don't see a real problem with (1): we do want to replace as 
much GNU
software as we can but not at the cost of making our life unnecessarily 
difficult.

No. 2 is something that has to be reported/submitted upstream before we can
adopt it. We do that with major components we take from other places and
it is the proven, safe way to do it.

No. 3 is something that seems necessary in any case: apparently the 
WITHOUT_RCS
option has been always broken.

I am currently reporting (2), but doing the /bin/ident part of (3) looks 
easy enough
that I may do it at a later time ;).

Pedro.