Quote:
It's a good idea Pink Floyd, but again, that's a Windows realm - contain all needed libraries within. Although this makes a very nice distribution system, you come across situations where two applications require the same library. Under the Windows way, 95% of the time, that library will be removed (forcefully), regardless of what it's needed by, if one of the applications is rendered useless (via upgrade or no longer needed).
Now you're left with a program that doesn't respond due to that missing library. And installing each application to its own directory, keeping privatized libraries, creates unnecessary bloat.
A possible counter for the bloat, is to have a *.pbi installer where it looks for applications which are known to contain libraries needed by the application you're installing, and create symlinks to those libraries (also diminishing the chance of broken dependencies), but then should the program containing that library be removed, you're left with nothing more than a non-functional program with a broken symlink dependency.
In the end, there are really only two choices, the Windows(.msi) and *.PBI way, and the Unix (dependencies) way.
|
I was thinking of PBI's to solve my current immediate problem.
It seems they have managed to do so.
For a universal installer system I wasn't suggesting a windows way of any sort. For a long time now and hopefully forever I will not consider running windows an option.
I still remember laughing my head off when I read about Gobo Linux storing libraries and programs in their own folder side by side. I have also violently abused windows for this method, it has given me far more headaches than the problem that started this thread.
I would suggest something in the way of:
all library's are put into /user/lib or something similar,
provided it conforms to the linux standard base in regard to directory structure. Everything is tracked in the same way as most packaging systems today. However the package simply must contain all library's required by the program's in a particular package.
When a package manager encounters an already installed or previous version of a library / dependency. The library or dependency is simply skipped or upgraded.
This would conclude the packaging format for either Linux, BSD.
If we could then achieve the same kind of thing for Linux / BSD (BSD includes Mac OS X), Solaris, React OS and maybe Novel Netware. We can now define a package encapsulation format that will be able to install every kind of program on any kind of commonly used operating system.
As stated above all member packages would keep their own libraries handy, but not be in-charge of how the libraries are used.
The master encapsulation format / master encapsulation package would just encapsulate these member packages.
The master encapsulation package would also include a python script to handle OS detection and hand the appropriate member package to the package manager or the appropriate operating system.
As the installer system requires a python runtime environment, any programmer can now make a python program, and then use a quick simple package maker program and walla. The program now works seamlessly on any common OS. All this with almost no effort from the end user, and no real extra effort from the developer.
Python would be the first language supported, as time progresses additional interpreted languages would be added to the specification e.g JavaME, JavaSE, C# etc.
Obviously, all programs contained in member packages would have to consist of byte code.
Any other language could probably be allowed as long as it could be defined and interpreted into byte code.
This method would NOT repeat NOT depend on the dot.net environment or definition. However overlapping use of languages may mean that the dot.net runtime environment would support nearly all programs from this install method.
I can see only one major problem with my proposal this far,
that being the possible size of the master packages containing these programs.
Any Ideas
Copyright 2007 Keith Emery.
