Proposed Package Maintenance Changes

Making Package Management Easier

Background - Database/Package management system

ConfirmDependencies uses the database to install and configure packages for use in an LMCE system. The is extrememly flexible in its ability to manage these packages and ensure that all required dependent packages are properly installed and configured, based on the devices that are installed on each Computer in an LMCE system. This system is extremely extensible and allows for multiple operating systems, multiple package management systems, cross OS and Distro repository sharing. Everytime ConfirmDependencies runs it guarantees all devices on a system have proper packages and dependencies installed and that any device configuration scripts are executed prior to use. The database stores:

1. a list of all packages that lmce requires for devices
2. OS and Distro Compatibilities for each package
3. multiple sources (repositories) for each package.
4. multiple OS and/or Distro compatibilitees for each of those sources.

Currently a new source must be defined each and everytime a new distro is released (intrepid, lucid, precise). A new package compatibility may also need to be defined. This is an extremely large and complicated system. The complexity makes it difficult for people to understand grasp the use of the management system.

Proposed Database/Package management changes

The following are my proposed changes:

• Use the Operating System field to seperate different linux releases (Ubuntu, Raspbian, Debian, Redhat, etc.).
  • Currently all Linux based OSes are grouped as one OS.
  • These systems are all different enough to warrant seperation.
  • Detection of different OSes would become MUCH easier (Ubuntu vs Raspbian vs Debian, etc) in scripts.
  • RepositorySource management becomes simpler/easier
  • Packages for an ubuntu system would not ever attempt to be sourced from an alien (ex. raspbian) repository, unless explicitly defined as a compatibility.
  • Currently it is confusing for devs to determine if a repository could be unintentionally considered as an alternate source (ex. right now a raspbian repository could be considered as an alternative to an ubuntu repository, if a package is not found, because they are defined as the same OS [linux]).
  • Autogeneration of sources.list at dvd creation, Diskless_Create, etc, becomes much easier with OperatingSystem seperated by flavour this way.
• Add a column to the Distro table that is Field: BaseRepositoryName, Type: varchar(30), Null: YES, Default: NULL.
  • This will hold the Distribution specific portion of the Repository Name (ex. intrepid, lucid, precise).
• Add a column to the Package_Source table that is Field: UseDistroInRepositoryName, Type: tinyint(1), Null: NO, Default: 0.
  • This will be a checkbox that tells ConfirmDependencies to add Repository (main)to the BaseRepositoryName (lucid) to the when the checkbox is ticked and BaseRepositoryName is not NULL.
  • If the BaseRepository is null or the checkbox is not ticked then existing (old) functionality would prevail.
• No change to existing behaviour, completely backwards compatible.

So, to illustrate my point, here is a before picture of the package source definitions:

And here is an after picture of what a completely cleaned up package source screen in webadmin could look like(*if* this was applied to previous releases, which it could be, by backporting a small change in ConfirmDependencies.cpp) [note the checkbox I refer to above is not shown here]:

Cross OS/Distro dependencies would still be capable of being defined the way they always have. The checkbox, that I refer to above, would be unchecked in this case to prevent the Distro name from being used in the repository field for ConfirmDependencies. In this example assume the checkbox referred to above is not ticked for the first source definition and is ticked for the second source definition. Result: if the package is from ubuntu presice it will be taken from the ubuntu repository and for all other Ubuntu or Debian OSes it would come from the debian stable repository (confirmdependencies prioritizes on distro match first, then OS).

If the package system is maintained well and device templates are created for most conceivable devices and confirmdependencies is used then entire package system could be much more tightly controlled, eliminating many errors and all around making things easier and more automatic from a user perspective.