Mailinglist Archive: zypp-devel (116 mails)
| < Previous | Next > |
[zypp-devel] Repository handling in installation
- From: Jiri Srain <jsrain@xxxxxxx>
- Date: Thu, 7 Jun 2007 11:37:12 +0200
- Message-id: <200706071137.16377.jsrain@xxxxxxx>
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@xxxxxxx
Lihovarska 1060/12 tel: +420 284 028 959
190 00 Praha 9 fax: +420 284 028 951
Czech Republic http://www.suse.cz
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@xxxxxxx
Lihovarska 1060/12 tel: +420 284 028 959
190 00 Praha 9 fax: +420 284 028 951
Czech Republic http://www.suse.cz
| < Previous | Next > |