What is this thread?
I like to define some terms to discuss installation using common language. I
noticed many times that many people have different meaning behind common use
terms. This makes discussion quite difficult because everybody talks on
different languages.
So I think we need first define terms and based on this terms we can go ahead
and discuss installation, packages, patches etc. Let me try to introduce some
math kind of definition for installation.
---------------------------------------------------
[B]Software[/B]
Software is set of files which represents some service to the customer,
something customers need to have on their computer to do their business.
Software may be in installed on computer - Installed state
Software may be not yet installed but on installation media, on CD, DVD,
install server filesystem etc - Distribution state
Software may be not yet compiled as a source files - Source state.
Software examples:
Solaris OS - this is what we are dealing with in general, however I think that
database like Oracle can be considered as Software also or Apache web server
etc.
Software may provide many services to the customers and so sometimes customers
may need only subset of this services. It may happen also that customers may
specifically need not to have certain services on their computers. So software
may be installed on computer as full image including all files represents all
services and it may be installed partially and represent subset of their
services.
[B]Dependency[/B]
Software files depends on each other. Some utility may need some libraries.
This dependancy may be mutual or not.
What does mean one file depends on other? It means that service represented by
this file will not work as expected. Of course this mean that there is no
algorithmic solution to determine dependancy - it is classical example of
nonalgorithmic task from Algorithm Theory. This mean that in real life some
dependancy will be always missed. However in theory we still may operate this
term to understand problem better.
If we take one file and marks all other files which this one depends on and
recursively mark their dependancy also, we will have subset of Software and
this subset can be independently delivered on computer and services represented
by this file and all other files included will work properly as expected and
may be some services of Software will not be present, but what is present will
work.
[B]Full Distribution Set[/B]
Lets for each file define this as Full Distribution Set (FDS). For some files
this Full Distribution Sets will be identical, because of mutual dependencies.
For some files FDS will be subset of other file FDS and in some cases they will
intersect, but of course this intersection will be also some other file FDS. It
will be nestling construction by construction method we choose.
Let assume that Software has 4 files A,B,C,D, E, F.
A and B mutually dependant and represent service Sa
C and D mutually dependant and represent service Sc
E and F mutually dependant and represent service Se
A depends on C
C depends on F
If we draw FDS for each files we will have three different FDS -
{A, B, C, D, E, F}
{C, D, E, F}
{E, F}
If we committed to deliver this Software to the customers each service then
each of this set should be available to the customer. And we should make sure
that customer will have only this three combination because any other
combination of files will not work properly.
[B]Distribution Unit[/B]
One solution bundle all files in three unbreakable set and distribute them as
three bundles. However it will be pretty natural to make next step and break
this Full Distribution Sets to Distribution Units (DU):
{A, B}
{C, D}
{E, F}
And define and enforce dependancy between DU so customer will not be able to
install {A, B} without {C, D} and {E, F}.
{A, B} DU for Sa depends on DU for Sc
{C, D} DU for Sc depends on DU for Se
{E, F}
This distribution bundling minimize space - which is not critical any more, but
also gives flexibility for the customer to combine independent FDS into single
image.
Let assume that in our example we have A depends on E not on C. Then we will
have different FDS picture
{A, B, E, F}
{C, D, E, F}
{E, F}
Which does not cover case when customers want to have both Sa and Sc on the
computer. But with DU available it will not be a problem to construct whatever
customers need.
Also DU allows customer to add services to already installed Software.
So Software will be distributed by set of DUs with dependancy set and enforced
by installation software. Please not that by the we DU is constructed it will
not be any mutual dependancy between DU.
----------------------------------------------------------
[B][I]Reality check[/I][/B]
Distribution Unit reflects what we call packages in real world. The real
packages are not DU in terms I defined, the way files are bundled together now
as I understand is in general up to the developers. However from installation
point of view major idea is that it is something which may be delivered
independently from other packages - may be on top of lower level packages.
Packages must not be mutually dependent - if this happen they should be one
package.
In terms just introduced - packages should not break DU boundaries, however
package may combine several DUs. For example it may turns out that all
utilities like ls, cat etc may be single DU for each utility because they
depends on common library but does not depends on each other, however having
package for each utility is not practical.
Of course this was about initial software distribution. I will continue with
Software updates -patching in following post.
vassun
This message posted from opensolaris.org
