On 12/21/05, Ian Collins <[EMAIL PROTECTED]> wrote: > Stefan Teleman wrote: > > >On 12/21/05, Ian Collins <[EMAIL PROTECTED]> wrote:
> Yes I remember that well and as you say, nothing has happened in the > interim. > > So, how can we move forward? Any common system must include Sun Solaris > packages as well, to avoid the silly situation John raised. > > Defining a means of identifying packages isn't hard, an agreed file > format and location should be all that is required. This can be a > simple text or XML file with the name, version and location of each > package. It could be appended to by a package post-install script and > scanned by a pre-install script to check the system for required > dependencies. > > Have I over simplified the problem and solution? If not, let's take > this forward. a bit, i think. i think GNU/OpenSource packages fall into three broad top-level categories: 0. software which never updates (example: gettextlib, which is considered done) 1. software for which updates are possible, but do not occur often (example: gdbm) 2. software which updates frequently (example: gstreamer) these three categories can each be further divided into three: 10. core (example: GNU fileutils) 11. application-specific dependency (example ffmpeg, which by itself is not very useful, but is required by Xine and many others) 12. toplevel application, which depends on 10 and 11 (example: Xine) and then there is the broad category of large-scale distributions, like GNOME and KDE, which have dependencies on all the types of software mentioned above, but which are also self-contained frameworks, with their own set of internal dependencies. i actually gave this some thought over the past few months. here's what i came up with, and this is just a suggestion. if it were up to me, i would build a relational database which describes: 0. each individual package, which has foreign key relationships to all the categories it belongs to 1. relationships between packages listed in 0, expressed as lookup tables based on unique numeric id's the advantages of doing this are: - managed inventory - well defined package categories - well defined package dependencies - a large scale package download (for example GNOME) becomes a join, and can be expressed as a checkbox on a GUI installer. figuring out what packages to install happens automagically behind the scenes, with the join, the user only clicks on "Install GNOME". - RPATH (which is an expression of dependencies) is also a join - no unnecessary downloads (they won't be part of the join) in terms of the actuall installation tool, i personally like very much Sun's WebStart install, which is used by the Companion CD. it's written in Java, it's GUI driven, therefore it's easy to use for installs, and it's also easy for uninstalls. if i were to implement this, i would do it in PostgreSQL on the backend and WebStart as the frontend. the user will only have to download a small Java application which is the installer driver, and presents them with a list of package choices. users can choose to only install a small package (for example gdbm) with one click, or they can choose to install the entire KDE with one click, or only install the fundamental modules of KDE plus just two additional modules with one click for the KDE foundation modules and two for each of the additionals. of course, the Java installer should also support command-line installs as well (for example: java-installer --nogui --list-packages followed by java-installer --nogui --install JDS --version 3.2.2). this also has the advantage of providing GPL compliance out of the box. the user can click a radio button labeled "install source" for anything they choose to install (for the GUI), and for the command line it's just an additional option: --install-source just my 0.02. --Stefan -- Stefan Teleman [EMAIL PROTECTED] _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
