RCS removed from base

Kiiski

Kiiski

I'm still shocked and not able to think clearly, so this post might be confusing o_O

When installing 12 to test machine and starting to test new configurations I noticed RCS was removed from base system.
This really came from bushes to me. I can't remember such old things, but I'm pretty sure I started using RCS and stuck with it, because I had false belief it would always be there.
So now I think I have to start converting my scripts and RCS archives to svnlite and more closely follow whats up with revision control systems in base to be more prepared next time it changes in base.

Hopefully this was just me and other people have more modern habits.
And I would be happy to hear if someone is willing to share some good advice for keeping track of important files in their systems.
 
Kiiski said:
When installing 12 to test machine and starting to test new configurations I noticed RCS was removed from base system.
This really came from bushes to me. I can't remember such old things, but I'm pretty sure I started using RCS and stuck with it, because I had false belief it would always be there.
So now I think I have to start converting my scripts and RCS archives to svnlite and more closely follow whats up with revision control systems in base to be more prepared next time it changes in base.
Click to expand...

It was already removed in FreeBSD 10.0, some time ago. However, it was preserved in the ports collection as devel/rcs57, so you can just install it (from ports or packages) and continue using RCS.

Personally, for managing local configuration files, I was using SCCS (or the GNU variant called CSSC) for a long time, because I was used to it from my old Solaris days. It's also in the ports collection. However, at some point I switched to Subversion because it is more modern, and it's supported by more software. For example, there's a Python library for SVN that I use for various things. But it's really just a matter of taste what you use for local revision control. If you're happy with RCS, by all means, continue to use it!
 
Well, ok, at least it was announced around that time, IIRC. The default for RCS in the base system was switched to “off” more than two years ago, see this commit. I don't know when it was actually removed, but I think it wasn't long thereafter. Of course, it took some time until the change made it to -stable.
 
At the moment my implementation depends on RCS being part of base system. So I can't just continue using it like now if it needs to be installed from ports. I guess it's smaller change to switch to svnlite, but I think this is good time to start thinking different approaches, which of course is not only a bad thing.
 
Kiiski said:
At the moment my implementation depends on RCS being part of base system. So I can't just continue using it like now if it needs to be installed from ports. I guess it's smaller change to switch to svnlite, but I think this is good time to start thinking different approaches, which of course is not only a bad thing.
Click to expand...
You mean that the path of the tools (/usr/bin) is hardcoded in your shell scripts? If you can't easily fix that, you could just create a bunch of symlinks, like this:
Code: 
pkg info -l rcs | grep bin/ | xargs -J % ln -s % /usr/bin
Then /usr/bin/ci will point to /usr/local/bin/ci, and so on.
 
Kiiski said:
At the moment my implementation depends on RCS being part of base system.
Click to expand...
That's unfortunate. You'll have to switch away from using RCS, as you said, or you'll have to fool your implementation into not noticing that RCS is not in base any more, as olli@ said.

BUT: The real root cause here is that your implementation should probably not have been sensitive to where its tools are installed in the first place. The unix-isa philosophy is usually: standard tools exist on the path somewhere, the path has been set correctly, and you don't need to worry whether it is /bin/ls, /usr/bin/ls, /usr/local/bin/ls, or /opt/something/ls, you'll get ls. There are exceptions to that general rule, for example when different packages end up having executables of the same name (unlikely to happen to something as basic as "ls"), or when you need to rely on the idiosyncrasies of a particular version, or when you need to run a real executable and avoid a shell builtin (commonly happens with /usr/bin/time, which gives different output from the shell-builtin time command).

So I agree that you should think about your general approach.
 
Problem is not how paths are set. Problem is that customization of vanilla FreeBSD needs RCS, configuring network and installing packages to name few. But at the moment best approach seems to be to change this whole concept somehow different. Lucky thing is there is no rush, so I will study this a lot more before doing anything :)
 
You must log in or register to reply here.
Back
Top