3 ms·
> For the casual Linux user, can you explain why './configure && make && make install' is a bad idea? Thanks. It isn't necessarily, given that the Autotools co
by derleth 14y ago
> For the casual Linux user, can you explain why './configure && make && make install' is a bad idea? Thanks.
It isn't necessarily, given that the Autotools configure installs to /usr/local by default, which is a directory tree explicitly reserved for installation of software outside the package system.
Installing shared libraries can cause problems, but that's rare because shared libraries are versioned in Linux, as opposed to Windows, which greatly reduces the incidence of DLL Hell. In short, a program might find a shared library that isn't the one it wants, but it very likely won't.
Similarly, installing your own executable files might cause problems for scripts. This could be more serious, but, in practice, I've installed a newer version of Perl outside the package system and everything works fine.
The biggest hassle of doing things outside the package system is the simple fact you don't have the package managers doing the scutwork for you. You have to do your own dependency tracking, your own configuration, and your own update management. There is no really easy way to uninstall anything. You quickly come to realize why we have package management in the first place, if you really go nuts with this stuff. ;)
So. The easy advice here is "Wait for the PPA", which the post itself mentions a few times. That will give you a nice little package, albeit not one from the official repos. I do that with VLC and couldn't be happier. But doing this little dance with Wine, building it yourself, is unlikely to cause problems if you follow the instructions.
- nitrogen 14y agoInstalling shared libraries can cause problems, but that's rare because shared libraries are versioned in Linux, as opposed to Windows, which greatly reduces the incidence of DLL Hell. In short, a program might find a shared library that isn't the one it wants, but it very likely won't. In fairness to Windows (and I never thought I would say that), .DLL files are now versioned via WinSxS (https://en.wikipedia.org/wiki/Side-by-side_assembly https://en.wikipedia.org/wiki/Side-by-side_assembly).
- beagle3 14y ago> In fairness to Windows (and I never thought I would say that), .DLL files are now versioned via WinSxS Apparently, that's not working as well as MS hoped, either from a technical or adopting perspective: From the same wikipedia article: - However, runtime libraries in Visual C++ 2010 no longer use this technology; instead, they include the version number of a DLL in its file name, which means that different versions of one DLL will technically be completely different DLLs now. - a bug in sxs.dll causes heap corruption, leading to application crashes. This issue is not fixed by any XP service packs. Users must manually install a QFE (Quick Fix Engineering). It should be noted that including the version of the library in the filename has been a simple solution that's been used in Unix since the early '90s, when shared libraries become fashionable. (Oh, Ultrix - how I hated not having shared libraries when I had to use you... Luckily, you're dead now)