openSUSE Lizards

Authors
Adrian Schröter (2)
Andrea Florio (1)
Andreas Jaeger (5)
Andrew Wafaa (13)
Arvin Schnell (1)
Bernhard Walle
Casual Programmer
Christoph Thiel
Christopher Hobbs
Cristian Rodríguez
Dirk Müller (1)
Duncan Mac-Vicar
Gabriele Mohr
Henne (1)
Hubert Mantel (1)
J. Daniel Schmidt (1)
Jan Blunck
Jan Madsen
Jan-Christoph Bornschlegel (1)
Jan-Simon Möller (4)
Josef Reidinger
Kevin Dupuy (6)
Klaas Freitag (7)
Klaus Singvogel
Ludwig Nussel (1)
Marcus Moeller (1)
Marcus Schaefer
Martin Lasarsch (3)
Masim Sugianto (16)
Michael Andres (1)
Michal Marek (3)
Michal Zugec
mrdocs
Peter Nixon
Peter Pöml (1)
Petr Mladek
Rossana Motta (1)
Rupert Horstkötter (1)
Stanislav Visnovsky (1)
Stefan Haas
Stefan Hundhammer
Stefan Schubert (1)
Steffen Winterfeldt (2)
Susanne Oberhauser
Thomas Schraitle (4)
Xin Wei Hu





 

Author Archive for Jan-Christoph Bornschlegel

Installation Source creation status

1 Star2 Stars3 Stars4 Stars5 Stars (2 votes, average: 5 out of 5)
Loading ... Loading ...
Friday, June 6th, 2008 by Jan-Christoph Bornschlegel

There is some work going on to put installation source creation functionality into kiwi.
At the moment kiwi can use prepared installation sources such as:

  • BuildService Repositories
  • mounted DVDs
  • FTP trees

But what if you have a local Build Service building some binary only packages and you wish tp make a installable media set from, say, “SLES + binary only drivers”?
You can use the inter-BS-Connectivity feature to only build the drivers (and not the whole distribution) in your BS and then create an installation source from your main BS project.

This is possible since release of the package kiwi-instsource which extends the functionality of the config.xmlfile to allow the compilation of an installation source from scratch.
Hereby “scratch” means directories containing .rpm and .spm files. Of course some information must be provided for the metadata creation — but this is also all in the config file (with one known exception — the PDB data).

The rest is figuring out which packages must be on the installation source.
Since it is perfectly ok to have conflicting packages in instsources, there is no dependency check or package resolving in this stage. The information must come from the user.

Therefore the package list may become rather long and I already plan to implement some simplification.
These plans include:

  • allowing more than one <repopackages> section
  • implement outsourcing blocks in separate files using XML functionality