Problems with the new versioning system

[Florin Braescu]

Hi everybody,

  In the last few days I was tested the new versioning
system introduced in lunar. Because in the same time i
was testing the new KDE 3.1.4 vesion, I wanted to
shout two rabbits with one bullet, so I have created a
new kde3/3.1.4 version. Using this new version I have
encounter some problems which I want to be described
here.

  To create a new version of a module is not
difficult. We may just create a new subdirectory in
the moonbase/$MODULE directory, named it with the new
version and copy the stuff of the moonbase/$MODULE
directory in the new subdirectory. After that we begin
to tweak the files to reflect the new changes.

  One first problem may consist in establishing the
location for installing the new version module. For
kde3 we use /opt/lunar/kde/3, so i have used for the
new version the /opt/lunar/kde/3.1.4 location. For big
modules like GNOME, KDE, XFCE, etc it's easy to use
such /opt/lunar/$MODULE/$VERSION location. It has the
advantage to have the stuff located in a delimited
place. It may be a problem for usual modules, if you
want to keep the old version too (the files will be
overriden by the new version).

  A second problem consist in overriding the common
files between different installed versions of the same
module. KDE use a /etc/profile.d/kde3.rc file to
specify the location of the modules. To have different
versions installed on the system we must create
versions for such files too.

  A third problem is running the new executables.
Linux use the PATH variable to search the first
executable with the asked name, and launch it.
In our case there could be many executables with the
same name, placed in distinct directories and is
difficult to select them. I can launch the startkde
program for version 3.1.4, but the KDE system will
launch after that the needed programs using the PATH
variable, so it will use the a previous version of
them if i do not modify the PATH value as needed.

  A fourth problem regards dependencies. KDE is a
integrated package of many modules. It's not difficult
to create and use a new version of it (after 
fixing the previuos problems). But related to it there
are many apps which may work in a large range of KDE
versions (usually we can see them in kde-apps,
kde-utils, games, etc directories in moonbase). Their
associated DEPENDS files contain such lines:
      depends  "kdelibs3"

  When we uninstall the kdelibs3 (the previous version
of KDE) building such a module will want to install
the depends modules again. So we must find a way to
point to the new versions. We can use
     depends  "kdelibs3/3.1.4" 
but the problem remains the same and it would be a
huge task to modify all the dependent modules in
moonbase when we will create a new version for KDE
(even considering scripts for that). At some point
some such modules may not work with the new versions.
For the modules which can be used in a large range or
versions we need to specify somehow a range of
depends, something like 3*, 3.1.3-3.1.4 or similar.

  Another related problem is what version is used for
building such modules. We can use a global variable
like 
   KDE_CURRENT_VERSION=3.1.4 
in a global config file (or deduce it somehow from the
installed moonbase) and use something like that
   depends "kdelibs3/$KDE_CURRENT_VERSION"

  Such modules are installed now in /opt/lunar/kde/3
directory. I belive we must use /opt/lunar/kde/apps,
/opt/lunar/kde/utils, /opt/lunar/kde/games,
etc directories for them for now on, to make the
install location independent of the version in use.

  As a final conclusion I can say that the new
versioning system is usable and valuable under some
restrictions posed by the problems described here,
until now. I am waiting for your ideas and comments
regarding this new issue.

Regards, 
  Florin
 

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com