The future of Linux - architecture and package inter-dependencies

[Mauro Mozzarelli]

> I think the first step would be to describe the problem in
> more concrete terms.  Actual problems that could be addressed,
> instead of vague generalizations that could apply to anything.
>
> Having concrete goals would be good, too.
>
> If the goals and the problem description are interesting and
> deemed realistic, then I'm sure developers would join your
> effort.
>

Here is an outline (anyone is welcome to reviewing it):

Main goal: to build a portable OS platform that allows for application
inter-operability and flexibility in the interchange of core indentifiable
components

Principles:
1) a component can be replaced without impact on other components
2) components' interoperability is defined by a contract (API) that
although can be extended, it cannot change the rules established in
previous baselines.

Main tasks:
1) to identify the core components
2) to identify independently repleceable groups of packages
4) to isolate the core components in replaceable units
5) to influence the development of critical software libraries and
components as services with a defined API that supports backwards
compatibility

This project requires the cooperation of the following roles:
1) OS architects
2) Packagers
3) package designers/developers


TASK 1: to identify core components
Key roles: all

This is a task that could be carried out by everyone through a
proposal/review process. The scope is to identify those components that we
would like to be able to replace (either new releases of the same
component or a different competing component) without impacting on the
integrity of the rest of the system. Core components can be product
suites, like desktop managers, vital libraries like "cairo" or
applications like openoffice.

An example could be:

Xorg
KDE
GNOME
cairo
Openoffice
Firefox
Mozilla
Apache
Java JVM/JDK
gcc
glibc

TASK 2: to identify independently repleceable groups of packages
key roles: packagers

Translating in real terms:
At the base of the success of this project is the cooperation between a
number of different roles that at present might not be happening. An
example could be the packager that takes care of building an "rpm" but is
not involved in the development and design of the packaged component.
The packager in this case would see a shift of his responsibilities from
passive package maker to architect and influencer, feeding specific OS
requirements to the components' designers.

Having that as our goal, we can start with this task that could be carried
out by the packager(s) alone.

The aim is to place the core components identified in TASK 1 in packages
groups.

Definition of package group: those packages that are dependent on each
other at release level and the replacement of one of them has an impact
on(requires the replacement of) one of more of the other packages in the
group.

We can expect that at present we will be able to identify several
intersecting (overlapping) package groups.

The completion of this task will add the following value:

1) to achieve a better understanding of the extent of the problem
2) to allow for an initial identification of packages in groups that if
replaced at once do not have an impact on the rest of the system, thus
enabling their replacement with newer or different groups.

TASK 3 - to isolate the core components in replaceable units
Key roles: OS architects, packagers, package analysts/developers

This is the task where we make significant changes to happen, and really
requires the buy in of all of the key roles.

If we are serious about this project, I propose to get a wiki
page/section, so that we can build and review this and more of the
documentation that we will require, keeping this mailing list as the
communication channel.

Please let me have your comments as soon as possible.
-- 
Mauro Mozzarelli
eMail: mauro at ezplanet.net