Philippe, you're absolutely right! Remove that dependency hell! Shams, you're arguments are correct as well.
Let's take a closer look to the .NET spirit: -------------------------------------------- 1. The applications are able to be installed by copy and paste only. That's really great because no user has got any trouble before he can start that application (especially non-power-users!). Better a user who is able to start your application than no users because they're all running into the dependency hell. The disadvantage is clear and Shams already said: when the libraries get an update, the application doesn't use them automatically. In that case, the developer has to pay attention to this circumstance and to update and distribute his application asap. This procedure is mostly acceptable for small, uncommon libraries. 2. More common libraries (for example GTK#) should get installed to the GAC because many other applications are based on this library. If there would be exploited a security hole then there would be a lot of related applications. By simply updating the GTK#, all those applications would be fixed. At the end, the developer has to decide which libraries are distributed to the GAC or to the application folder. Okay, that is the theory. ------------------------- In reality, there is no linux installer and no tool for automatic install of libraries to the GAC. 2nd, the GAC is not complete, as I've read. That's why I suggest to deploy applications - only in the meanwhile - by variant 1 and copy all needed libraries into the same application directory. That helps a lot for all programmers who cannot spend days and nights to the mono project, but are very interested in developing linux solutions. As soon as possible, those common libraries should get installed to the GAC and there should be a small installer tool to do this job. If the installer of MonoDevelop detects, that there haven't been installed GTK# libraries, then it should install that version of the GTK# libraries which have been packaged to the install program of MonoDevelop. The result ---------- Has anybody got time and motivation for creating a minimal installation tool? Or maybe Installshield? Wise? Jochen -----Urspr�ngliche Nachricht----- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Philippe Lavoie Gesendet: Samstag, 3. April 2004 21:44 An: Shahms E. King; [EMAIL PROTECTED] Betreff: RE: [Mono-list] About RPMS of .NET packages (using MonoDevelop asa case study) You are right, patching all potential applications might be hell. By the way, what is the mechanism used within the GAC to deprecate a version due to security fixes? Philippe Lavoie Cactus Commerce eBusiness. All Business. Tel 819.778.0313 x302 * 888.CACTUS.0 * Fax 819.771.0921 www.cactuscommerce.com [EMAIL PROTECTED] -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Shahms E. King Sent: Saturday, April 03, 2004 1:58 PM To: [EMAIL PROTECTED] Subject: RE: [Mono-list] About RPMS of .NET packages (using MonoDevelop asa case study) This solves exactly one problem while creating many, many more. "disk space" is not the only concern. Bugfixes, patches, etc. are also important. Imagine, if you will, a world in which every managed, non-core, assembly is installed privately by the application. All of these applications are effectively statically linked to that version of the respective libraries. Now, say a security problem is discovered in one of the dependent libraries so the administrator dutifully updates the system library to fix the problem. Of course, you may not have been aware that the library was in use by that application, let alone using a private copy of it. So the security problem persists until the developer of that application decides to update it. There are many, many other ways of solving the dependency problems you mentioned, even in the UNIX world. Packaging things like that makes perfect sense for "technology demonstrations" or "/opt" but is, quite frankly, idiotic to do on a system level. Especially considering .NET assemblies support interface versioning at a more fine grained level than simple ELF versioning. Parallel installable libraries is just one way of alleviating the "dependency hell" on UNIX and, unlike Windows, it works quite well. -- --Shahms _______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list _______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
