* package management
* distributions
* features
* strategy

In this work i try to show the potential of different packet management systems and their different capabilities and features. A later and far more important step will be finding a way to get a synthesis of the systems resulting in a new system. A major issue with all these different systems is that they enforce duplicate/redundant work steps upon all it's users - a synthesis between these systems shall reduce this issue.

A main principle will be deployment and not creating "yet another linux distribution"!

The core problem

  • Packets are build per Distro(distribution) (ignoring inheritance as debian -> ubuntu here)
  • Patches on packets - made by the Distribution developer - are not noticed by upstream
  • assignment of distribution specific bugs and upstream bugs are complicated
  • no automation in building packets (as in gentoo) for most distros - a developer has to do that
  • no authentification (as in debian) for most distributions - was the packet modified?! 
| developer team | ------------------ | distribution | ------------------ | user |
      |                                       |
   bug management                       bug management

   (upstream)

<graphviz border='frame' format='png'> digraph G {Hello->World!} </graphviz>

things i have to do before creating anything new

  • analyze capability of different systems and how much these systems already implement the concept of this work
  • analyze the 'work flow' of ppl doing releases and packing software (take this into account)
  • considering the new features (i have added at the end of this work) analyze how much work it will be to create a system of that scale and get it up and running
  • getting a minimal system running maybe with a modular approach so that components can be refined over time.

Introduction

The problem: Distributing software and automated build systems. 

What really annoys me about Linux is that if a software is not found in a repository one has to install it with the scripts provided by upstream.

Of course this is not specific to Linux however since i mainly use Linux it happens often. Using open source software on other systems as windows can be even more annoying since there is no package manager and one has to build not only the application but also all libraries by hand.

With this i try to find a conceptional approach to make the creation of packages and to handle the dependencies in a easy and cross platform manner.

The goals are:

  • Abstraction layer between upstream and downstream
  • centralized (first generation, later decentralized)
  • for OpenSource and for ClosedSource Software
  • automated build system for packages
  • examples: Software like the 'Qt library' or firefox
  • verification of the package creation
  • the whole building step (every element of the build chain) must be verifiable in the sense that all compiler/linker steps are done with a virtual architecture to get identical results (for security). if the same package is build on different archs the results must be the same
  • structurized and syncronized building of stable/testing/unstable trees
  • this is typical for debian and other binary distributions
  • on the other hand Gentoo has a very interesting principle to do minor updates all the time to keep the system up2date.
  • security (vulnerabilities, exploits)
  • downstream/midstream patches should get into upstream as soon as possible
currently this is a big issue since distributions patch software but patches don't get upstream for various reasons
  • midstream should hold exploit reports for all kind of upstream/midstream packages
  • security of binary packages
  • build a hash (as gentoo does already) but also using gpg signatures
  • verfifizierte Toolchain
to validate a software for confidentiality/security it is not enough only to validate the software itself but also other components which are (with no static linking) dynamicaly linked. It is also very important to validate the used toolchain as compilers and linkers or runtime environments as python or java for instance. If these tools cause a security issue it might require to rebuild it (if static linking as used) or rebuild only the library (dynamic linking) if there still is ABI compatibility after the fix.

guidelines for installing software

unix

  • Unter unixartigen systemen sowas wie in [13] oder [14]. BSD macht das anderst als Linux.

microsoft

microsoft has a certification program, check "the designed for windows" guidelines

  • they validate drivers
  • they use the 'all content in one folder' principle (ignoring the registry or links from the start menu). this is true for most userspace applications.

package management definition:

There are different layers of package management, here an introduction:

  • no management:
    programs are used from the place they are in. for example one downloads software with firefox it's the $HOMEDIR/Downloads/myprogram.exe from where the software is started.
    other programs just install all the fils into various directories running a script (that is equivlent to 'make install')
  • uninstaller:
    programs install into a chroot environemnt and if all files are tracked they are actually installed into the system while a list of these fils is keept for later package removal.
  • updaters:
    the software has an active component (a scheduled component) which periodically checks for updates. Often this happens at program launch
  • distribution specific hierarchical management(distribution internal builds):
    per-distribution (not limited to linux distributions). In this operation mode packages are created within the distribution. A distribution specific centralized and unique program (as portage for gentoo) managed all the software and software updates.
    in this mode packages are usually created within the distribution which means that the buildsystem will NOT fail if a package misses a dependancy while another package pulled the same dependancy already into the distribution. In this case the build will work if that library happens to be installed already. If that library is not installed it will prompt with an error message as: 'could not find header file SDL.h' and you will get lots of 'undecalred objects'.
    this is typical for: gentoo but also most other linux distributions
  • distribution specific hierarchical management(external builds):
    in this mode the package is not created or related to already 'installed components' directly. in contrast typing: 'gcc myfile.c -o myfile' would be since it is NOT generated using and build environment (portage for example is a build environment but portage does not use 'external builds')
    the package is generated by a set of tools which might monitor all OPEN system calls (of course all other important calls as well). If any of that calls resolves into a file which is not part of a package the build step MUST fail.
    • the suse buildservice implements 'external builds'
  • globaly centralized hierarchical packet management (von nun an GHM)

was macht ein GHM aus? - macht auch minimal builds - ist aber nicht distributions spezifisch, sondern wird nur von der distribution ausgefuehrt und am schluss kommt ein paket dabei raus

  • dieses system wird die naechste grosse evolution sein. warum? rekapitulieren wir ueber distributionen allg.: siehe "warum distributionen?"

why distributions?"

you might think: one for all?! actually thats plain wrong since a distribution is an individual adaption of a system to a specilized environment as:

  • a community of users
  • used hardware (architecture)
  • used hardware (scale of performance as mobile phone vs desktop computer)
  • complexity of single components (full featured desktop distro vs. embedded system)
  • security aspects
  • quality requirements
  • community and commercial support
  • ...

summary: a distribution is only a subset of programs taken out of a pool of 'programs' which are composed to fit special requirements.

using a GHM could accelerate the development of distributions.

important: GHM -> distribution -> enduser

Das Problem

Was wir brauchen ist sowohl Aktualitaet als auch Stabilitaet und das Endproukt sollte via Mausclick installierbar sein.

Leider widersprechen sich diese im Wesentlichen zwei Anforderungen teilweise. Nehmen wir z.B. die Debian Distribution, fuer welche hunderte von Paketen uebersetzt sind (also deb's), sieht man sehr schnell wie komplex die Sache ist.

Die Idee, des verteilten Paketerstellen ist einfach, jedoch sind einige Erfordernisse vorhanden. Dabei brauchen wir genau ein solches System, wie es unter Debian schon sehr gut implementiert ist.

  • Stable
  • Testing (hier sind Pakete enthalten, welche dann nach validierung stable werden)
  • Unstable (oder unuseable?, sicherlich manachmal)

Warum? Die meisten Benutzer wollen nicht den ganzen Tag updates via "apt-get update; apt-get upgrade" durchlaufen lassen. Dazu kommt, dass dies auch nicht jeder kann, da es mindestens eine Flatrate erfordert oder die Preise koennen astronomisch hoch werden. Mal ganz von den hiermit verbunden Problemen der Verteilung abgesehen ist ein solches Konzept eines "Fertigsystems" nicht verkehrt, da wiederum viele Benutzer eine einmalige Installation wuenschen, die oftmals nicht haeufig upgedatet wird.

Aber: Welche Vorteile ein Releasesystem noch hat ist hinsichtlich des Paketekonzepts nebensaechlich, da wir uns auf den nun wesentlichen Aspekt konzentrieren werden - der Paketebau.

Ob nun rpm oder deb Paketformat ist im Prinzip egal, da sich beide sehr aehnlich sind, im Wesentlichen haben beide die selben Probleme:

  • erstellen eines Paketes erfordert Kentnisse ueber dessen Abhaenigkeiten
  • erstellen kann problematisch sein, da man ev. zu aktuelle libraries installiert hat und ein downdate nicht in Frage kommt
  • erstellen eines Paketes erfordert Vertrauen, ich vertraue am liebsten dem Debian Project, aber viele wichtige Pakete sind nur in contrib zu finden.
  • Paketersteller ist nicht gleichzeitig der Projektmaintainer

bypassing packet management

hier gibt es mehrere problemfelder, ich greif mal ein paar auf:

  • pakete welche man selber installiert da sie nicht im paket management enthalten sind z.b. exotische programme die von randgruppen verwendet werden
  • open office extensions wie z.b. [3]
  • firefox plugins (grosses sicherheitsproblem): flash aber auch addons
  • php scripte zusammen mit mysql
  • perl z.b. die perl library und die user programme darin
  • spiele: installation von zusatzsoftware wie 'karten' bei ut2004 oder bei taspring
  • kartenmateriel wie z.b. OSM - karten bei marble

einzustufen ist das so:

  • bypassing ist bei ausfuehrbarem code bedenklich.
  • bypassing ist bei content aergerlich, da z.b. mehrere user gleichen content im ~ lagern muessen, also platzverschwendung.

im allg. ist solche software schwer 'sauber' zu entfernen

Die Abhaenigkeiten

Wir schauen uns diese Probleme nun mal im Einzelfall an:

Zu aktuelle Libraries der Entwickler

Ich illustriere das an einem Beispiel. Im MusE Project, wo ich selbst taetig bin, wird fast immer mit den aktuellsten Versionen entwickelt, also sind auch diese Libraries meist von den Entwicklern selbst uebersetzt worden. So kommt im Program selbst Qt3.2 zum Einsatz, aber die Entwickler haben Qt3.3 installiert.

Wenn man nun "qt3-develop" der Qt3.3 Serie verwendet, speichert der die erstellten widgets gleich wie die Qt3.2 serie ab, aber aus eventueller Inkompatibilitaet setzt er einen Verweis:
File generated with too recent version of Qt Designer (3.3 vs. 3.2.3)

Diese Problem laesst sich zwar nicht umgehen, wenn nun die Entwickler ein Release ihrer Software planen, jedoch kann der Paketebauer auf eine Umgebung zurueckgreifen, welche eben die Qt Version installiert hat, die auf dem System als aktuell gilt. Beim compilieren der Software stoesst er nun auf die Fehler, welche beim compilieren auf seinem Rechner verborgen waren. 

-Stable
 |-libjack             \
 |-libsnd               |> MusE 0.7.1
 |-qt       3.2.3      /
-UnStable
 |-libjack             \
 |-libsnd               |> MusE 0.7.1
 |-qt       3.3        /

Vertrauen in den Paketersteller

Dies ist ein ganz wichtiger Punkt fuer Unternehmen wie Privatnutzer. Dieses System koennte mit einem pgp-key die Software, also das deb oder rpm file signieren und es somit zumindest als vom Entwickler erzeugt und signiert ausweisen. Solche ansaetze sind im Wesentlichen schon in den gaenigen Debian releases enthalten.

Paketersteller != Projektleiter

Meist sind Projekteleiter nur am Anfang der Entwicklung des Projektes mit der Verteilung der Software betraut. Sobald das Projekt komplexer wird, uebernehmen diese Aufgabe andere Leute. Bei den meisten Programmen werden die Pakete von den Debian Package Maintainern betreut, welche oft nicht viel mit dem Projekt zu tun haben.

weitere probleme

  • das paketbauen muss so einfach sein, dass eine software von extern z.b. abhaenigkeiten im tree referenziert und damit integrierbar ist. so kann man sicherstellen, dass software von extern leicht integrierbar ist.
  • im sinne eines overlays sollten allerdings nicht nur pakete sondern auch abhaenigkeiten integrierbar sein. ziel: bei einem groesseren paket-merge wie z.b. kde und alle kde programme kann man dann z.b. exklusiv von extern via overlay verwenden und kann die im system liegenden abhaenigkeiten entweder erweitern oder auch komplett ueberschatten

load balancing issue

packets should be specified, not their origin. this means it MUST NOT matter if a packet was downloaded from:

  • p2p network
  • client/server downloads
  • a friend via local share
  • or in general any media a packet could be 'accessed' from

Platformen die obige Konzepte teilweise implementieren

  • launchpad
  • sourceforge
  • codeplex [17]
  • google code
  • savannah
  • freshmeat
  • autopackage
  • suse build service [7]

siehe auch [2]

beispiel zu heutigem deployment

programm wird entweder statisch oder dynamisch gelinkt. z.b.:

  • hauptprogramm selbst
    • qt lib
    • libX
    • libY
    • libZ

im statischen fall ist man recht schnell fertig. im dynamischen wird dann z.b. das programm und die dll files in ein verzeichnis geschoben und der loader (also wenn man das hauptprogramm.exe anclickt) laed dann die *.dll files welche libX.dll, libY.dll und libZ.dll usw nach.

vorteil:

  • einfach zu machen, deployment geht schnell
  • entweder mit installier/uninstaller
  • hersteller proprietaerer software koennen user zum update zwingen wegen sicherheits-loechern in alten ;-)
  • oder alternativ mit exe packer als ein grosses exe file welches via resource files usw alle daten entheallt

nachteil:

  • fehler in einer lib erzwingen auch ein neues release des programmes (das klingt fuer windows nutzer vielleicht normal, aber linuxnutzer kennen sowas eigentlich nicht da dort immer nur die libs upgedatet werden (da meist die ABI kompatibel zur security-gepatchten lib ist).
  • man hat keine uebersicht welche libs das programm nun braucht
  • man hat ev. zwei mal die gleichen libs rumliegen (das native qt und das im deployten paket)
  • auf lange sicht gesehen ist sowas ekelig zu supporten, da man alles doppelt machen muss:
    • updates in der lib muss man selber machen und neu deployen
  • man kann libs nicht mehr anfassen (ich glaube hier ist ein beispiel noetig)
    • spiel: ut2004 hat die openal.so (das ist eine dll unter linux) und ich hab fuer openal-soft ja das pulseaudio backend programmiert. mein problem war nun wie bekomme ich ut2004 dazu meine .so zu verwenden und nicht die wo im /opt/ut2004 dir rumlag. man kann das entweder via LD_LIBRARY_PATH machen oder man loescht einfach die im /opt/ut2004 verzeichnis und dann sucht der linker autoamtisch unter /lib und /usr/lib nach der .so und nimmt die. so koennte man natuerlich auch cheaten und das spiel veraendern darum ist das teilweise hier nicht gewollt in diesem fall ist das allerdings offensichtlich nicht so.

links

todo


Retrieved from "http://lastlog.de/wiki/index.php/CrossPlatformPackageManager"
Powered by MediaWiki