AW: [Mono-list] About RPMS of .NET packages (using MonoDevelop asa case study)

[Jochen Wezel]

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=FCngliche Nachricht-----
Von: mono-list-admin@lists.ximian.com =
[mailto:mono-list-admin@lists.ximian.com] Im Auftrag von Philippe Lavoie
Gesendet: Samstag, 3. April 2004 21:44
An: Shahms E. King; mono-list@lists.ximian.com
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
=20
   Cactus Commerce         eBusiness. All Business.
 Tel 819.778.0313 x302 * 888.CACTUS.0 * Fax 819.771.0921 =
www.cactuscommerce.com philippe.lavoie@cactuscommerce.com

-----Original Message-----
From: mono-list-admin@lists.ximian.com
[mailto:mono-list-admin@lists.ximian.com] On Behalf Of Shahms E. King
Sent: Saturday, April 03, 2004 1:58 PM
To: mono-list@lists.ximian.com
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  -  Mono-list@lists.ximian.com =
http://lists.ximian.com/mailman/listinfo/mono-list