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 <p...@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.

_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to