AW: [Mono-list] About RPMS of .NET packages (using MonoDevelop asa case study)
Mon, 5 Apr 2004 12:21:31 +0200
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 =
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 =
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 =
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.
Has anybody got time and motivation for creating a minimal installation =
tool? Or maybe Installshield? Wise?
Von: firstname.lastname@example.org =
[mailto:email@example.com] Im Auftrag von Philippe Lavoie
Gesendet: Samstag, 3. April 2004 21:44
An: Shahms E. King; firstname.lastname@example.org
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?
Cactus Commerce eBusiness. All Business.
Tel 819.778.0313 x302 * 888.CACTUS.0 * Fax 819.771.0921 =
[mailto:email@example.com] On Behalf Of Shahms E. King
Sent: Saturday, April 03, 2004 1:58 PM
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.
Mono-list maillist - Monofirstname.lastname@example.org =