Sahil ModGill <scorpionking.sahil@...> writes: > > > > > > > here is the problem: > > I want to develop a version control tool (in open source) which can take > > care of different versions of one component at execution time i.e. If one > > application request for earlier version, system will automatically allocate > > that component and if latest version is required, then that will be > > provided by the model/system itself. This facility is available in .NET > > technology in Microsoft. I want to develop this type of tool in open source > > which take care of all available versions of same component for different > > applications at system level.
One of the problems with Microsoft is its inappropriate use of technology to further business needs. It started out as an OS for a single-user on a single machine and then tried to extend that in contorted ways to become a multi-user on multiple machines OS while still supporting the SUOASM approach. .NET is an especially sore issue for me because I spent some frustrating hours yesterday trying to get MS Windows 8 to install an already downloaded version of .NET instead of repeatedly failing to download (most likely) the same version from the Update server. In a multiple-OS, heterogeneous environment, it is better that the application choose the correct version of its dependent libraries, not the OS. Under AFS, a fileserver might store multiple versions of executables and shared libraries (different architectures - sun4, sun5, i386, amd64). Specific example, Perl for SunOS, Solaris, FreeBSD, Linux, etc. A Linux machine will then only get the relevant set of directories mounted and only see the right SOs. Projects can set up their own environment variables to pick up modules from the right locations (from the mounted filesystems here). Or set up ld.so.conf. A dynamic executable (of an application) pulls in its libraries at run-time. In a properly configured environment, which in Linux depends on the packaging system, not on the operating system, the installer should set up the correct links needed for all the executables in an application to run. The installation should fail if the minimum required versions of its libraries are not already installed. Any half-way decent packaging system will keep a list of dependent packages, versions, and conflicts for an app. For library upgrades on a Linux system, it is the responsibility of the Linux distributions to repackage simultaneously those applications which no longer work with the upgraded library version. It doesn't make sense to have the kernel and core libraries (my definition of the Linux OS) decide which SO version should be used by a particular application. Obviously, if there are calls to missing/changed functions, OS error messages should be copious and clear. > What she want to know is: > > For example: Let's assume, Software A needs Python 3 and Software B needs > Python 2.7 for it's execution and in our system we have both versions of > Python. When user executes any software (A or B) system automatically > allocates required Python libraries and keeps tracks of it. In Perl, it is possible to specify an exact module version to be imported. See http://stackoverflow.com/questions/260593/how-can-i-install-a-specific-version-of-a-perl-module?lq=1 and http://stackoverflow.com/questions/14332254/how-can-i-use-specific-version-of-a-perl-cpan-module Python has virtualenv which lets you set up multiple very specific environments of Python and modules on the same machine (I've not used it, though). On my Linux machine, python<tab> returns: python2, python2.7, python3, python3.2 Just python starts python2.7 > Is there any tool in Open Source which helps us to understand this problem? Note though that both Perl and Python have their own packaging "apps" (CPAN and ActiveState/pypi/etc.), which are independent of a Linux distro's packaging app. and in fact the OS itself. So, e.g., you can install either the libdevice-serialport-perl deb package on Debian and its derivatives or the Device::SerialPort Perl package/module on any OS, including MS Windows. > Please share your views and experiences. Dependency tracking at various stages of an application's use (compile, link, install, run, upgrade) is not an easy task, but I don't recommend spending time on integrating it into the OS or the "system". IMHO, it would be better to improve packaging scripts or environments so that the resulting package plays well with installer applications [1]. Just be aware a fine balance may be needed between being overly strict and overly permissive when it comes to specifying required versions. HTH, Sameer [1] In the AFS environment above, it would be very nice to have a package installation that updates client machine config files to point to project-specific network-mounted filesystems. E.g. ld.so.conf. _______________________________________________ ILUGC Mailing List: http://www.ae.iitm.ac.in/mailman/listinfo/ilugc ILUGC Mailing List Guidelines: http://ilugc.in/mailinglist-guidelines
