|
|
|
Installation / Update Service for QKW / KDE and apps
|
|
|
|
|
|
|
|
Jaroslaw Staniek
|
|
|
|
started: 2003-07-22
|
|
|
|
|
|
|
|
OOPL-only: Create Update Service using tdecore/KMD5 and bzip2 lib. This would be used to automatic
|
|
|
|
updates for QKW and Kexi packages at the end-user side. Two options:
|
|
|
|
- offline update from local archives
|
|
|
|
- online update from the company ftp resources
|
|
|
|
Benefits:
|
|
|
|
- Updating would not longer require uninstal+install scheme.
|
|
|
|
- Settings could be stored safer between updates.
|
|
|
|
- User could be notified about new features and fixes installed.
|
|
|
|
- User could add/remove components.
|
|
|
|
- Everything using consistent gui on all platforms.
|
|
|
|
- 'Batch/net installation' options for enterprises.
|
|
|
|
- Smart 'Fix installation' option.
|
|
|
|
- Possibility of collecting user settings and infos about installations. These can optionally transferred
|
|
|
|
to developers with a bug report to help find a bug context.
|
|
|
|
- This is a step for making KDE apps packages distribution-neutral on Linux.
|
|
|
|
Notes:
|
|
|
|
- The Service guis and backend should be build from two parts:
|
|
|
|
- First: qt-only that is used to initialize the process and check the system, independently
|
|
|
|
from existing KDE sybsystem.
|
|
|
|
- Second: used when we already know we already have a working KDE subsystem. This part can use
|
|
|
|
KConfig, KLibLoader, etc. to change the KDE settings.
|
|
|
|
- To be able to do this, KDE needs get more guidelines for distributors of its binaries.
|
|
|
|
- To be usable for commercial use, there should be one packaging system for KDE
|
|
|
|
(maybe on top of tgz/rpm/deb/win32/mac?), "Meta Packaging".
|