Sophie

Sophie

distrib > Mageia > 7 > armv7hl > media > core-updates > by-pkgid > 68c0c2ff89d8bf9051ff1b9773ed48e4 > files > 9497

libzypp-doc-17.9.0-1.1.mga7.noarch.rpm

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "https://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/xhtml;charset=UTF-8"/>
<meta http-equiv="X-UA-Compatible" content="IE=9"/>
<meta name="generator" content="Doxygen 1.8.15"/>
<meta name="viewport" content="width=device-width, initial-scale=1"/>
<title>libzypp: Services</title>
<link href="tabs.css" rel="stylesheet" type="text/css"/>
<script type="text/javascript" src="jquery.js"></script>
<script type="text/javascript" src="dynsections.js"></script>
<link href="navtree.css" rel="stylesheet" type="text/css"/>
<script type="text/javascript" src="resize.js"></script>
<script type="text/javascript" src="navtreedata.js"></script>
<script type="text/javascript" src="navtree.js"></script>
<script type="text/javascript">
/* @license magnet:?xt=urn:btih:cf05388f2679ee054f2beb29a391d25f4e673ac3&amp;dn=gpl-2.0.txt GPL-v2 */
  $(document).ready(initResizable);
/* @license-end */</script>
<link href="doxygen.css" rel="stylesheet" type="text/css" />
</head>
<body>
<div id="top"><!-- do not remove this div, it is closed by doxygen! -->
<div id="titlearea">
<table cellspacing="0" cellpadding="0">
 <tbody>
 <tr style="height: 56px;">
  <td id="projectalign" style="padding-left: 0.5em;">
   <div id="projectname">libzypp
   &#160;<span id="projectnumber">17.9.0</span>
   </div>
  </td>
 </tr>
 </tbody>
</table>
</div>
<!-- end header part -->
<!-- Generated by Doxygen 1.8.15 -->
<script type="text/javascript" src="menudata.js"></script>
<script type="text/javascript" src="menu.js"></script>
<script type="text/javascript">
/* @license magnet:?xt=urn:btih:cf05388f2679ee054f2beb29a391d25f4e673ac3&amp;dn=gpl-2.0.txt GPL-v2 */
$(function() {
  initMenu('',false,false,'search.php','Search');
});
/* @license-end */</script>
<div id="main-nav"></div>
</div><!-- top -->
<div id="side-nav" class="ui-resizable side-nav-resizable">
  <div id="nav-tree">
    <div id="nav-tree-contents">
      <div id="nav-sync" class="sync"></div>
    </div>
  </div>
  <div id="splitbar" style="-moz-user-select:none;" 
       class="ui-resizable-handle">
  </div>
</div>
<script type="text/javascript">
/* @license magnet:?xt=urn:btih:cf05388f2679ee054f2beb29a391d25f4e673ac3&amp;dn=gpl-2.0.txt GPL-v2 */
$(document).ready(function(){initNavTree('zypp-services.html','');});
/* @license-end */
</script>
<div id="doc-content">
<div class="PageDoc"><div class="header">
  <div class="headertitle">
<div class="title">Services </div>  </div>
</div><!--header-->
<div class="contents">
<div class="textblock"><dl class="section author"><dt>Author</dt><dd>Duncan Mac-Vicar P. <a href="#" onclick="location.href='mai'+'lto:'+'dma'+'cv'+'ica'+'r@'+'sus'+'e.'+'de'; return false;">dmacv<span style="display: none;">.nosp@m.</span>icar<span style="display: none;">.nosp@m.</span>@suse<span style="display: none;">.nosp@m.</span>.de</a></dd></dl>
<p>Services provide a list of repositories. So when the service is refreshed, the repositories specified by the service service is synced with the local repository list.</p>
<h1><a class="anchor" id="service-types"></a>
Classes of services</h1>
<p>There are two classes of services:</p>
<h2><a class="anchor" id="services-remote"></a>
Remote Services</h2>
<p>Remote services are a subscription to a remote server, that provide a list of repositories that will be synced with the previous list of repositories for the same service.</p>
<p>By default, the remote services list is stored in the /etc/zypp/services.d directory in standard INI files. Each file can contain more than one service.</p>
<p>The format is the following:</p>
<pre class="fragment">[servicealias]
name=My Service
url=http://customers.maintenance.company.com/service
enabled=true
autorefresh=true
type=nu
</pre><p>The type "nu" stands for Novell Update, which gives a customer the repositories it is entitled to access. The type "ris" is an extended version of the "nu" type. Additionally, the file could contain "repostoenable" and "repostodisable" entries, which contain a list of repository aliases to enable or disable on the next refresh. This line is modified by other programs to force enabling or disabling a certain repository.</p>
<p>From the remote side, the service url needs to provide a repoindex.xml file with the repository list:</p>
<pre class="fragment">&lt;repoindex&gt;
  &lt;repo url="http://foo.com/repo1" alias="a repository 1"/&gt;
  &lt;repo url="http://foo.com/repo2" alias="a repository 2"/&gt;
...
&lt;/repoindex&gt;
</pre><h2><a class="anchor" id="services-plugin"></a>
Plugin Services</h2>
<p><a class="el" href="zypp-plugins.html#plugin-services">Plugin services</a> are simple scripts that return a list of repositories. They are installed locally in the system using packages. For each script installed ZYpp will “see” a service of type “plugin”. When you refresh the service, the repositories this script returns as output will be added (or removed and kept in sync if they change afterwards).</p>
<p>A plugin service is a program installed in /usr/lib/zypp/plugins/services.</p>
<p>Once a program called "foobar" is installed, listing services will show it:</p>
<pre class="fragment">&gt; zypper ls
#  | Alias            | Name         | Enabled | Refresh | Type
---+------------------+--------------+---------+---------+-------
1  | foobar           | foobar       | Yes     | Yes     | plugin
...
...
</pre><p>When this service is refreshed, the program will be executed and it will return the list of repositories in the same .repo files format that can be found in /etc/zypp/repos.d:</p>
<pre class="fragment"># output returned by the plugin

[repo-oss]
name=oss
enabled=1
autorefresh=0
baseurl=http://download.opensuse.org//distribution/11.4/repo/oss
type=yast2
keeppackages=0

...
</pre><p>As you can see, the main advantage of plugin services is that they can read information from the client and calculate the repository list from there. Nothing prevents a plugin service to still interact with a server to get the repository list.</p>
<p>The main disadvantage is that you have logic in the client side that in case of bugs or changes, needs to be updated.</p>
<p>Spacewalk integration is implemented using plugin services. The plugin talks XML-RPC to the server and asks for the list of channels the system is subscribed to. The plugin needs to read the server address and perform the login.</p>
<p>However, the spacewalk plugin service does have an extra indirection, as the repository list returned are not plain urls, but urls of the type plugin:$name?params, which use the urlresolver plugin to get the real url. This is not necessary, and here it is done because it allows to add custom headers to the HTTP requests. You can read more about urlresolver plugins <a class="el" href="zypp-plugins.html#plugin-url-resolver">Url Resolver plugins</a> here.</p>
<h1><a class="anchor" id="service-refresh"></a>
Refreshing services</h1>
<p>Using zypper, you can refresh services by executing</p>
<pre class="fragment">zypper refs
</pre><p>The repositories that are listed in the service will be added, using the reposotiy alias specified in the service index prefixed by the service alias: e.g. "myservice:myrepository". Repositories that vanished from the service will be automatically removed.</p>
<h1><a class="anchor" id="service-examples"></a>
Example usecases</h1>
<h2><a class="anchor" id="services-usecase-1"></a>
Usecase #1: The project with multiple repositories and layers</h2>
<p>Imagine the following usecase (with this one I am using some real request from our KDE guys)</p>
<p>The build service provides a KDE4 repository. Which in turn requires the Qt4 repository, because is built on openSUSE 11.0 + the new Qt4 repo.</p>
<p>When looking at this problem, repository dependencies is what comes to head in the first place. But forget about them. If package dependencies are complicated right now, imagine adding a secondary (and duplicated) layer of information. Packages already know their dependencies.</p>
<p>Now imagine our KDE guys can provide an URL, which you add to zypper. And this url returns a dynamic list of repositories. And zypper adds and remove repositories based on the information returned by this url on every refresh.</p>
<h2><a class="anchor" id="services-usecase-2"></a>
Usecase #2: Update repositories based on the customer</h2>
<p>This is actually where services where originated. Services were present in Novell ZenWorks. How it works?</p>
<p>The service url nu.novell.com is added to the system. But in this url also a customer id is present as a http username. When you registered, Novell knows the subscription and products this system is linked to and what entitlements the customer has. The service can then return a dynamic list of repositories based on the customer preferences, products and entitlements. The customer does not need to keep them manually in sync.</p>
<p>Now that we don’t have Zenworks in the base system, we still want this cool functionality for our customers, therefore ZYpp now implements services natively.</p>
<p>Technically, this even allows us to offer hotfixes to L3 supported customers on the fly: the system is marked on the server side as being hotfixed, and an extra temporary repository with the PTF (Problem Temporary Fix) packages is added to this system list of repositories.</p>
<h2><a class="anchor" id="services-usecase-3"></a>
Usecase #3: Dynamic repository collections</h2>
<p>You are a build service user, and you have an account, and of course you have a list of watched projects you are interested to. What if you could keep your system repositores in sync with your watched project list.</p>
<p>Or what if the build service could offer a service based on keywords or other data: like <a href="http://build.opensuse.org/services/mostpopular/repo/repoindex.xml">http://build.opensuse.org/services/mostpopular/repo/repoindex.xml</a> would contain dynamically the 15 most popular repositories. You add that service, and then ZYpp does the work for you of adding new popular repositories, and remove the old ones.</p>
<h1><a class="anchor" id="service-impl"></a>
Developers: Implementation</h1>
<p>Services are implemented in the following classes:</p>
<ul>
<li><a class="el" href="structzypp_1_1repo_1_1ServiceType.html">zypp::repo::ServiceType</a> (Service types enumeration)</li>
<li><a class="el" href="classzypp_1_1parser_1_1ServiceFileReader.html">zypp::parser::ServiceFileReader</a> (.service file parser)</li>
<li><a class="el" href="classzypp_1_1ServiceInfo.html">zypp::ServiceInfo</a> Information about a service (.service file data)</li>
<li><a class="el" href="classzypp_1_1repo_1_1PluginServices.html">zypp::repo::PluginServices</a> (Services as plugins)</li>
<li><a class="el" href="classzypp_1_1parser_1_1RepoindexFileReader.html">zypp::parser::RepoindexFileReader</a> (NU and RIS remote service index XML parser)</li>
<li><a class="el" href="classzypp_1_1repo_1_1ServiceRepos.html">zypp::repo::ServiceRepos</a> (Repositories in a service) </li>
</ul>
</div></div><!-- PageDoc -->
</div><!-- contents -->
</div><!-- doc-content -->
<!-- start footer part -->
<div id="nav-path" class="navpath"><!-- id is needed for treeview function! -->
  <ul>
    <li class="footer">Generated by
    <a href="http://www.doxygen.org/index.html">
    <img class="footer" src="doxygen.png" alt="doxygen"/></a> 1.8.15 </li>
  </ul>
</div>
</body>
</html>