Hi! Find below the document describing what's required from libzypp for installation of the distro. Jiri Repositories in Installation ============================ locilka, 2007-06-06 jsrain, 2007-06-07 This document describes where and how are software repositories used within the installation or update process. Types of Repositories --------------------- There are two basic types of repositories we use: * Base Product - The base product we are installing or updating to * Add-On Products - Additional products * Currently Installed Products - In case of product upgrade Location of Repositories ------------------------ There can be many types of location of repositories. All products, even the base one, can be remote. So we can have these kinds of repository locations: * Local * CD/DVD * ISO on Disk * Unpacked Repository on Disk * Remote * HTTP * FTP * NFS * Samba * ...? Where Do We Need To Handle Sources ---------------------------------- First there is the initial step of the installation: * Base Product It needs to be initialized after the installation mode is selected (either a new installation or an update). We actually only need to create the product entry in ZYPP, no additional information is needed there. The product control file needs to known from the begining of the installation but it is actually copied to the root of the inst-sys. * Add-On Products They can be added just after the installation mode is selected or also during the installation proposal (Add-On Proposal). For these products, installation.xml is downloaded as well as y2update.tgz and the content file of the product is inspected because we need to gather the product name to be shown in the UI. * Currently Installed Products This is a special case of installation - an upgrade. In this step, we don't need to know more than installed product names that are taken from the /etc/SuSE-release file. Then there is the installation/upgrade-proposal step: * Base Product Here we need to know all patterns, packages ... that are part of the product to make a proposal. * Add-On Products The same as for Base Product, patterns and packages need to be known. * Currently Installed Products In case of upgrade, all installed packages need to be known. I guess that installed patterns are not evaluated at all. We might need this information a bit sooner - in the 'Select Desktop' dialog. Then there is the installation Write() state: * Base & Add-On products Here we need to download additional workflows for patterns to merge them into the installation workflow. This means that all patterns on the media need to be known, but patterns need to be known already anyway. * Currently Installed Products We might think about dropping the information about packages installed on the system (in case of update) here. The proposal is already accepted and after the installation, the information will be gathered from the "current" system status. Then a Finish Installation step is called: * Base & Add-On products I'm not sure how Libzypp database with installation repositories used withing inst-sys is copied to the Target system. It's probably done via some Pkg-bindings call either at the end of the installation or rather just after the installation (Write) starts, maybe both. Summary of Needed Information ----------------------------- * When initializing the installation environment and adding Add-On products, the only information we need is the product resolvable (including dependencies). Maybe some product dependencies are needed too but this is solved somewhere in Libzypp. When an additional product has its own control file, it needs to be known but for getting the file Pkg::SourceProvideOptionalFile function is used. Media and product resolvables needs to be available immediatelly (even for the dependency solver), other resolvables can be downloaded/created later in background. If there is a problem with source initialization in two stages (1st media and products, 2nd other resolvables), then - base source must be initialized (meaning solver can perform operations on it) before the first add-on product is added - add-on product source must be initializes in order to finish the add-on media addition (in case of multiple products in source user is asked which one to install) - dependency on other add-on products (added before) must be possible to be checked by the solver If it is not possible (too risky) to perform any operation on background, source addition can be kept as it is (for 10.3) * When the installation/upgrade reaches the installation/update proposal, all resolvables are needed: products, patterns, packages and even maybe patches if an online update source is added as an add-on (that might happen). Downloading these pieces of information can be done in a background process not to disturb user with: | Downloading file ftp://server/some_file... | | [================75%======>______] | That might make the installation faster, mainly when remove Add-On products are user. But there is an exception we need to take care about: If the product is on a removable media (CD/DVD/USB...?), we need to 'download' all the resolvables before changing the media (but only when we need to change the media because of, e.g., Add-On on another CD). * When the installation starts (installing RPMs, and so long...), also patterns of used workflows need to be known. * Either in the inst_finish or when the disk is formatted and installation starts, we need to know all the data to write it to the target disk, e.g., installed products. * During inst_finish, following operations need to be perfomed: Sources Management - move the information about sources to the target - merge information about sources existing before (add as disabled, for 10.3->10.4 beavior can be changed) - move the raw cache to the target Database - move to the target - merge with existing one (10.3->10.4 upgrade) - ensure that old sources are moved to database (immediatelly or at the beginning of 2nd stage) Target - need to convert information about products/patterns/... if not the original XML format is used (upgrade) - conversion may be done earlier, but definitly after the instlalation proposal -- Regards, Jiri Srain YaST Team Leader --------------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: jsrain@suse.cz Lihovarska 1060/12 tel: +420 284 028 959 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz