I have some changes made to NetSNMP source code and must use ./configure to bind it with my system. I have an existing version of NetSNMP which i may have to revert to later.
IF i use configure, does it overwrite on my prev files?
I just want to be sure that every time i use configure command be it when I use old code or new code, it overwrites the files right?
This may sound silly but it is just that I am going to make an important change and I dnt want to lose the old system state.
I’m not intimately familiar with NetSNMP – some of this is package-dependent. But as a general rule:
1 - When you re-run ./configure, all it will rewrite is the configuration files in the source directory. That’s safe.
2 - When you re-run make, it will recompile any changed files. This typically will only overwrite the finished product(s) in the source directory (but I’ve run across some exceptions in the past).
3 - When you run make install, it will overwrite the binaries for sure. It may overwrite the config files with default settings, but that’s really package-dependent.
If you’re worried about saving your current setup, you’ll need to find out where NetSNMP puts its binaries and config files and manually copy them.
If there’s someone here who’s really familiar with that package, of course, they can offer more specific tips and advice.
Actually this isn’t true as most of the binary files would have different names being a different version, however symlinks may be replaced, but often times it’s possible to have different versions os the same library/application without having problems.
Also note that is you installed from an RPM originally then it was probably installed to /usr whereas typically software built form source installs to /usr/local.
./configure --help is usually a good bet
Usually there is a file called Install in the top level of teh source directory and it’s usually a good idea to read it along with the Readme.
Oh, man, I have to respectfully disagree. While some file types (the Linux kernel itself being a good example) include a version string in the name, with a generic symlink on the system, that is NOT true of most user-space executables.
For a very common example, if you download the source and build a new version of bash, the executable is called simply that: “bash.” It’s installed as /bin/bash. So … if you build that new package, you’re going to wipe out the previous version of bash.
I’ll grant your point about directories, but you still can’t depend on that. If you do, I don’t want to be the one who has to clean up after you.
Once again, I speak from painful experience. My advice to the poster came from an abundance of caution. If you just assume that a downloaded source package won’t hose an existing install, you’re going to get … well, hosed.
The fact that there may be more then 1 version of a given package installed is why pkgconfig was developed it’s also the reason that many configure scripts that require a given package can be built and linked against a specific version if more then one version is installed by passing the appropriate argument to configure.
Also as I mentioned when building from source the default is for the binaries to be installed to /usr/local. For example, in your example for Bash. If you go to Index of /gnu/bash and download bash and read the install file you would see that it defaults to /usr/local for the install. Therefore it would not overwrite Bash in /usr/bin. As well using configure you can usually specify a directory (prefix) with configure. If there could not be different versions of the same executable installed there would be no which command.
Of course. No argument there. But what you initially said might have caused the user just to hammer his existing Net-SNMP installation. Not being familiar with the package, I chose the path of caution.
You’d do well to follow that advice, too. (You obviously haven’t been burned by this yet … as I have!) I checked, and yes, you’re right about bash – as downloaded directly from GNU (or a direct GNU mirror). But as a general rule, assuming that the default will always be “/local/bin” is going to get you into deep trouble.
But what really frightened me was this statement in your original post:
Actually this isn’t true as most of the binary files would have different names being a different version …
Again, this is simply not true for most user-executable program. It’s true for the kernel, drivers, libraries and things like that, but that blanket statement was misleading, and could get someone into deep trouble.
Finally, just as a general principle, before you upgrade to a different version on ANY package, unless you’re sure that you’ll never want to go back to the old one, you ALWAYS back up. ALWAYS. That’s just common sense. Fingers can fumble. You might miss a config “prefix” option as it rolls past in a terminal. Smart people (especially those who’ve been burned!) ALWAYS back up before doing something like this.
That’s personal opinion, but one based on hard experience (I’m going to quit saying that now). You, and anyone else reading this, are free to do as you wish.
Someone who knows more about Net-SNMP needs to pop in and help the original poster with precisely what might need to be backed up (if anything).
If no one else responds, try this: if you originally installed Net-SNMP with Yast, go back into Software Management, search for that package, and you can get a file listing. That’s clunky, but it’ll show where all the files went.
This tells make to install everything relative to /opt/netsnmp (including all config files) so it won’t overwrite anything. You can use whatever you want for a prefix, but typically somewhere in /opt is used.
Another person suggested running ./configure --help, there is much more information there.
