http://wiki.rosalab.com/en/api.php?action=feedcontributions&user=Domtheo&feedformat=atomRosalab Wiki - User contributions [en]2024-03-28T17:41:17ZUser contributionsMediaWiki 1.26.4http://wiki.rosalab.com/en/index.php?title=Release_notes_ROSA_Marathon_2012&diff=8269Release notes ROSA Marathon 20122014-04-14T06:51:26Z<p>Domtheo: </p>
<hr />
<div>==About ROSA 2012 Marathon==<br />
===2012->2013->2014->2015->2016->2017===<br />
<br />
ROSA 2012 Marathon is a LTS (long time support) release with guaranteed security and software updates for 5 years. Based on Mandriva/ROSA 2011 repositories with lots of improvements and updates. It is recommended for Enterprise, SMB and SOHO which do not need the "bleeding edge" technology, but require stable software and ability to work for a long time without reinstalling the system. This is the first release completely built using the ABF system.<br />
<br />
You can find additional information about ROSA 2012 Marathon in its [[ROSA 2012 Marathon tour| tour]] and some information about known issues and workarounds at the [[Errata_ROSA_Marathon_2012|Errata page]].<br />
<br />
==Distribution==<br />
<br />
ROSA 2012 Marathon is available in the following editions:<br />
<br />
1. ROSA 2012 Marathon LiveDVD KDE4 (pure Free Edition) for i586 and x86_64 architectures. For default enabled ONLY main media.<br />
<br />
2. ROSA 2012 Marathon LiveDVD KDE4 Extended Edition for i586 and x86_64 architectures, including non-free components and proprietary software (such as multimedia codecs). Note that laws of some countries may forbid usage of some of these components! In this release added and enabled main, non-free and restricted media.<br />
<br />
'''Available community editions:'''<br />
<br />
3. ROSA LXDE 2012 community edition for i586 and x86_64 architectures (see [[ROSA LXDE 2012 community edition summary]]).<br />
<br />
4. ROSA Marathon 2012 GNOME community Edition for i586 and x86_64 architectures (see [[ROSA Marathon 2012 GNOME community Edition summary]] and [[Restricted and non-free components of ROSA Marathon 2012 GNOME Community Edition]], free from proprietary components ISO is available as well).<br />
<br />
==System requirements==<br />
<br />
* 780 MB RAM (recommends 1Gb)<br />
* 10 GB free HDD space<br />
* VGA display with resolution 1024x768<br />
* Keyboard, mouse<br />
* DVD/flash for installation<br />
<br />
==Deprecation==<br />
<br />
GNOME, Xfce and other Desktop Environments (DE) and Window Managers (WM) are no longer included in the official ROSA packages. Contribution packages from the ROSA community are available for these desktop environments however. Only KDE4 is officially supported. If you need ROSA with another DE or WM you can use unofficial packages or distributions prepared by community members.<br />
[http://www.goldenfibreglass.com/product-atap-fiberglass.php Atap fiberglass], [http://www.grosir-kosmetik.com/63-been-pink-beauty-series.html Been pink], [http://www.raywhitesemarang.com Properti semarang], [http://www.grosir-kosmetik.com/62-glutera.html Glutera]<br />
<br />
==Common components==<br />
<br />
===Kernel and system stack===<br />
<br />
* Kernel 3.0.28 LTS desktop with/without PAE desktop/notebook and server edition<br />
* Dracut 17<br />
* Systemd 39<br />
* GCC 4.6.1<br />
* udev-173<br />
* rpm 5.3.12<br />
* pulseaudio 2.0 rc2<br />
<br />
=== Hardware support===<br />
* Hardware base for April 2012<br />
* Updated drivers for Intel, NVidia and AMD graphics cards with support for i3/i5/i7, GF6xxx and latest AMD chips<br />
* Mesa 7.11<br />
* Basic support for Nvidia Optimus technology with Bumblebee (not included in DVD, but may be installed later from the Main repository)<br />
* Updated printers and scanner base<br />
<br />
===Improved ROSA-specific system stuff===<br />
<br />
* Draklive-install<br />
* Drakxtools<br />
* Drakx-net<br />
<br />
We have updated and improved functionality of these components in the following areas:<br />
* Hardware support for modern devices<br />
* Improved installer with lots of fixes<br />
* A lot of patches and fixes developed after ROSA 2011 release<br />
<br />
<br />
===Removed deprecated ''drakconf'' modules===<br />
Some deprecated ''drakconf'' modules are removed.<br />
<br />
Please refer to the [[Drakxtools Replacements]] page for the list of removed modules and suggested replacements.<br />
<br />
===Network===<br />
* NetworkManager 0.9.2<br />
* KnetworkManager 0.9<br />
* VPNPPTP 0.3.0<br />
<br />
===KDE===<br />
* KDE 4.8.2 with ROSA fixes and improvements<br />
* Rosa theme with updated KDE-decorator<br />
* SimpleWelcome<br />
* RocketBar<br />
* Dolphin 2.0<br />
<br />
===Enterprise stack===<br />
* Improved wizard for connecting Windows Active Directory domains<br />
* OpenJDK is installed by default. For Oracle Java JDK/JRE please visit the official Oracle Java [http://www.oracle.com/technetwork/java/javase/downloads/index.html Downloads page]. '''NOTE''': see [[Howto install proprietary Java from Oracle]]<br />
* LSB support<br />
* Updated Perl/Python stack<br />
* Kerberos<br />
* Samba<br />
<br />
===User applications===<br />
* Mozilla Firefox 10.0.2 LTS<br />
* Mozilla Thunderbird 10.0.2 LTS<br />
* LibreOffice 3.4.5<br />
* Amarok 2.0.5<br />
<br />
[[Category:ROSA Marathon 2012]]<br />
[[ru:Release_notes_ROSA_Marathon_2012]]</div>Domtheohttp://wiki.rosalab.com/en/index.php?title=Release_notes_ROSA_Desktop.Fresh_R1&diff=8268Release notes ROSA Desktop.Fresh R12014-04-14T06:49:57Z<p>Domtheo: </p>
<hr />
<div>==About ROSA Desktop Fresh R1==<br />
<br />
'''ROSA Desktop Fresh R1''' is a new code name for a new distribution from ROSA Fresh series. The '''R''' series of distributions is targeted to those users who looks for fresh and full-functional software. This series is developed by ROSA with significant help of community.<br />
<br />
New users will get a fast high-quality system combining advantages and improvements of successful ROSA Fresh platform with fresh and stable software components.<br />
<br />
Users who already work in ROSA Desktop Fresh 2012 are able to update their systems to ROSA Desktop Fresh R1 from official repositories. For avoid migration problem please read article [[Issues and workarounds for migration from ROSA Desktop Fresh 2012 to R1]]<br />
<br />
You can find some information about known issues and workarounds of the release at the [[Errata_ROSA_Desktop_R1|Errata page]].<br />
<br />
==Distribution==<br />
<br />
ROSA Desktop Fresh R1 is available in the following editions:<br />
<br />
1. ROSA Desktop.Fresh R1 LiveDVD KDE4 Extended edition for i586 and x86_64 architectures with preinstalled codecs and proprietary components. Main, Non-free and Restricted repositories are enabled by default.<br />
[http://digiadvertise.wordpress.com/2014/04/07/jasa-seo-di-jakarta Jasa seo]<br />
<br />
'''Additional editions (soon):'''<br />
<br />
2. [[ROSA Desktop Fresh R1 LXDE]] for i586 and x86_64 architectures.<br />
<br />
3. ROSA Desktop Fresh R1 GNOME Edition (GNOME 3.8.x).<br />
<br />
==System requirements==<br />
<br />
* 780 MB RAM (recommends 2Gb - for the Live mode, as well)<br />
* 10 GB free HDD space<br />
* VGA display with resolution 1024x768 and PnP and EDID support<br />
* Keyboard, mouse<br />
* DVD/flash for installation<br />
* Graphic cards: NVIDIA 8xxx and higher, ATI/AMD 5xxx and higher, Intel 965 and higher (HD series). Support for older cards is performed only by means of free drivers or can be absent at all. <br />
<br />
==Release Details==<br />
<br />
=== Desktop Environment ===<br />
<br />
=====General=====<br />
Thanks to new rasterizer from Adobe and Google, font smoothing has been improved significantly. <br />
<br />
ROSA graphical theme has got a lot of modifications:<br />
:- Completely new slide show in the installer. <br />
:- New decoration for window titles (with "shadow" support). <br />
:- Renewed the set of widgets included to RocketBar by default. <br />
:- Implemented our brand ROSA Elementary theme for Chromuim/Google Chrome. <br />
:- Fixed issues discovered in the QgtkStyleAlt theme engine. <br />
<br />
=====KDE 4.10.3=====<br />
<br />
Besides migration from 4.9 to 4.10 by itself, one should highlight the following:<br />
: - fixes of several regressions in upstream 4.10 (in particular, fixed losing focus in lock screen password window when pressing the Alt key, including the case when one uses Alt+Shift for keyboard layout switching - [https://bugs.kde.org/show_bug.cgi?id=319935 KDE bug #319935])<br />
: - fixes for several bugs that have been present in upstream KDE for years (for example, partial reset of user settings concerning appearance after launch of KCM KDM - [https://bugs.kde.org/show_bug.cgi?id=254430 KDE bug #254430])<br />
: - fixes of different cosmetic issues<br />
: - improved quality of localization<br />
<br />
ROSA brand-name tools:<br />
:- TimeFrame is now able to show video directly in the preview window. <br />
:- TimeFrame is now integrated with KLook. <br />
:- A new widget "All desktops" (Expo) has been added to RocketBar which displays all user desktops in a single grid. Number of virtual desktops available for user right after installation is increased from one to four.<br />
<br />
The core ROSA features remain in place in the new KDE:<br />
: - a set of brand-name widgets (Simple Welcome, Stack Folder and others) used by default<br />
: - integration of Dolphin file manager with KLook tool used to preview files of different types<br />
: - extended KDE CC settings of font smoothing (possibility to enable/disable byte-code interpreter)<br />
<br />
Later we will present updated Gnome 3.8.2 and LXDE desktops and ISO images based on them<br />
<br />
===User-level Software===<br />
<br />
* Libreoffice 3.6.6<br />
* Firefox 21<br />
* Thunderbird 17.0.5<br />
* Chromium 27<br />
* ROSA Media Player 1.6<br />
<br />
ROSA Desktop Fresh R1 includes the new version of ROSA Media Player - 1.6 - with the following new features: <br />
:- complete integration with YouTube, including video search, possibility to choose stream quality, etc.<br />
:- possibility to record presentation from display and add audio from microphone or line-in. <br />
:- improved IPTV support;<br />
:- DVD menu support;<br />
:- significantly renewed module responsible for Internet browsing. <br />
<br />
===Cloud Support===<br />
<br />
Windows Azure is a cloud computing platform and infrastructure, created by Microsoft for building, deploying and managing applications and services through a global network of Microsoft-managed datacenters.<br />
<br />
Support for creation of Linux-based virtual machines is provided by RedHat, Novell, Canonical and some other vendors. And from now on, ROSA repositories also provide all necessary packages, tools and patches required for deploying guests with ROSA Fresh in Windows Azure.<br />
<br />
Below you can find instructions on how to prepare virtual appliances:<br />
* [[Azure]]<br />
<br />
===New packages===<br />
<br />
* Steam - now you can connect this service and get access to a large variety of Linux games out of the box (requires proprietary NVIDIA or AMD video drivers). Note that Steam is targeted to 32-bit systems only, but you can try to use it in 64-bit system at your own risk.<br />
<br />
===System part===<br />
<br />
* All repositories are now connected and enabled out of the box, so user can get system updates just after installation<br />
* In 64-bit systems, main and non-free repositories for 32-bit platform are enabled by default to make it possible to install such programs as skype, wine, teamviewer, steam and others that are absent in 64-bit repositories.<br />
<br />
* Kernel 3.8.12<br />
BFQ and zswap are disabled by default due to stability reasons<br />
<br />
* Dracut 27<br />
The latest version for kernel 3.8.x series<br />
<br />
* Systemd<br />
* usermod changes<br />
<br />
The code has been merged with upstream (Fedora). Currently two modes are available for consolehelper: root with password request (link to config-util) and root without password (config-util-user). Now consolehelper-based programs should be organized in the following way: primary file (xyz) should be placed to /usr/sbin/ or other folder not accessible by user, /usr/bin/ should contain a link to consolehelper, there should be a rule named /etc/pam.d/xyz with content like the following:<br />
#%PAM-1.0<br />
auth include config-util<br />
account include config-util<br />
session include config-util<br />
<br />
(or config-util-user)<br />
<br />
and description in /etc/security/console.apps/<br />
<br />
Draksec has been rewritten to use new rules. All other programs that use consolehelper have been updated, too.<br />
<br />
* Modifications in sysvinit subsystem<br />
<br />
As a part of migration to systemd, old init scripts have been completely dropped from the following subsystems:<br />
<br />
** DM subsystem. Dropped prefdm and lookupdm scripts. Added systemd services for the main DMs - KDM, GDM, SLiM, LightDM. Now to choose a DM one should run '''systemctl enable ''xyzdm''.service'''; to disable it, run '''systemctl disable ''xyzdm''.service'''. Note that configuration line in /etc/sysconfig/desktop related to DM selection is ignored from now on. DM can be also switched using drakedm.<br />
<br />
** Network subsystem. drakx-net has been completely dropped, we have also dropped network-up and network-auth parts from init scripts. Now we only have CLI (network) and NM subsystems.<br />
<br />
* Added patches for X-Server 1.13.3 to improve monitor detection<br />
* Intel video driver updated to 2.21.6<br />
* NVIDIA 319.17 and NVIDIA304 (for cards prior to 8xxx) 304.88<br />
* AMD Catalyst (fglrx) 13.4<br />
* NetworkManager 0.98<br />
* Complete migration to NM. drakx-net subsystem has been completely dropped.<br />
* urpmi and rpmdrake now don't calculate orphaned packages by default; this significantly speeds up package installation and removal.<br />
* urpmi and rpmdrake now install updates more aggressively - when updating a single package, by default all its dependencies will be updated automatically.<br />
* '--download-all' option for urpmi is now set by default to avoid problems with large updates.<br />
* pm-utils is replaced with systemd.<br />
<br />
Power management is now performed using systemd. For compatibility with KDE, a hybrid solution based on modified upower is used.<br />
<br />
* Consolekit и PolicyKit are completely dropped from the system<br />
<br />
These components are obsolete and now they are replaced with systemd analogues. Session management is now performed by means of logind.<br />
<br />
[[ru:Примечания_к_релизу_ROSA_Desktop.Fresh_R1]]</div>Domtheohttp://wiki.rosalab.com/en/index.php?title=Packaging_HowTo&diff=8267Packaging HowTo2014-04-14T06:48:34Z<p>Domtheo: </p>
<hr />
<div>{{introduction|This HOWTO Tutorial is aimed at helping people who want to produce software packages which should integrate well in the ROSA distribution of GNU/Linux. In particular, it will stress in what way the packages are slightly different from the packages anyone would write for other rpm-based distributions. This document should be useful to ROSA developers, but also to external people.<br />
}}<br />
<br />
{{Warning|Building RPM's as root is dangerous, because the binary files are installed on the system before being packaged, thus you must always build as normal user so you won't accidentally damage your system.}}<br />
<br />
<br />
== Foreword ==<br />
It is assumed in this document that the reader is "linux-ready". He/she already knows the basic commands, directory structure and has already used rpm, at least for installing packages.<br />
<br />
This document is constructed as a step-by-step recipe to create an rpm package, that can integrate well into the ROSA distribution of GNU/Linux, from either a previous source rpm or from a tar source.<br />
<br />
RPM roughly means three things:<br />
<br />
* a program intended to install or create packages,<br />
* a format used in packages (source or binary) created by the program rpm,<br />
* a file called package which contains either a binary or sources along with an information header about how to install/uninstall the program.<br />
<br />
The program {{prog|rpm}} is, from the user's point of view, a powerful package manager. It acts as a "conductor" for any action on rpm packages. Amongst other things, it can:<br />
<br />
* install or upgrade a package and verify dependencies,<br />
* while installing a package, perform actions in order to make the installed program ready to use,<br />
* restore accidentally erased files belonging to a package,<br />
* check if a package is already installed,<br />
* find to which package a particular file belongs,<br />
* verify the current installation as to the fulfilment of dependency requirements of installed packages,<br />
* .... <br />
<br />
From the programmer's point of view, the rpm program is a packager which encapsulates, in a single rpm file, all the information needed to install a program on a given platform.<br />
[http://www.goldenfibreglass.com/product-atap-fiberglass.php Atap fiberglass], [http://vamostech.com/gps-tracking Gps tracking], [http://vamostech.com/gps-tracking Gps tracker], [http://www.awanirentcar.com/pricelist Sewa mobil jakarta]<br />
<br />
It is important to distinguish from the beginning, the difference between source ( {{file|.src.rpm}} ) and binary ({{file|.<archtype>.rpm}}) packages.<br />
<br />
The first one contains (yes you guessed) the complete source tree from the original programmer, plus all the stuff the packager added in order to configure, compile and install the program. It generally consists of a spec file (the file used to instruct rpm which operations it has to perform, in order to create the package) along with patches, if any.<br />
<br />
The second one contains the compiled binary, and all the files (documentation, config files, icons,...) that will be installed on the target system. It also contains the procedure used to place the files in their correct location and the actions to perform in order to make the program operable.<br />
<br />
== Preparing the software ==<br />
=== The basics ===<br />
Although RPM was originally designed to work with [http://www.redhat.com Red Hat Linux], it also works on other rpm-based distributions: [http://wiki.rosalab.ru/index.php/%D0%97%D0%B0%D0%B3%D0%BB%D0%B0%D0%B2%D0%BD%D0%B0%D1%8F_%D1%81%D1%82%D1%80%D0%B0%D0%BD%D0%B8%D1%86%D0%B0 ROSA], [http://www.mandrivalinux.com Mandriva Linux], [http://www.suse.com/index_us.html Suse], etc ; {{prog|rpm}} is already installed on these systems.<br />
<br />
ROSA uses an offspring of Red Hat's RPM, RPM5. You can get the vanilla rpm5 distribution [http://rpm5.org/ here].<br />
<br />
Rpm5 is backwards compatible with rpm4, and the specs prepared for rpm4, which most rpm-based distributions use, should work with rpm5; of course, they must also comply to ROSA policy.<br />
<br />
=== Building for ROSA ===<br />
<br />
Building packages for the development version of ROSA is always subject to small patches and enhancements to the {{prog|rpm}} program in use. To use the very exact rpm build tools used at our build system, download the development version of ROSA first. Then, install through your package manager (see [[Docs/Basic_tasks/Installing_and_removing_software|Installing and removing software]]) the following packages:<br />
<br />
* The package {{pkg|rpm}} which is our patched version of RPM5 (should already be installed);<br />
* The package {{pkg|rpm-build}} which contains scripts used to build packages;<br />
* The package {{pkg|rpmlint}} which is used to check the validity of the generated {{file|src.rpm}}.<br />
<br />
In the rest of this howto, "rpm" means the rpm5 version shipped with ROSA.<br />
<br />
== Preliminary actions ==<br />
=== Create required folders ===<br />
<br />
rpm5 creates all required directories automatically, there's no need to do this manually.<br />
<br />
=== Do not create .rpmmacros file ===<br />
<br />
Guides for some distributions say that you should create an {{file|~/.rpmmacros}} file to add some personal information to your packages, such as %packager, %vendor, etc. Do not do this. The build scripts run inside the build system assign these fields automatically.<br />
<br />
== Building an RPM package ==<br />
=== From a source package ===<br />
This is generally the case for the packages which are already included in the distribution.<br />
<br />
The latest rpm files from cooker are available on many mirrors whose list is available at [[Development/Mirrors|Cooker Mirrors]]. There you will find under '''TODO: verify mirror list''':<br />
<br />
* SRPMS for source rpms (main, contrib, jpackage, others) and under the cpu architecture (e.g. i586, x86_64, ...):<br />
* media/main for main binary rpms.<br />
* media/contrib for contrib binary rpms.<br />
* media/jpackage for noarch binary rpms. <br />
<br />
When you find the source rpm you want to modify for ROSA, just issue {{cmd|rpm -ivh mypackage.src.rpm}}; it will install all source files into your {{file|RPM}} directory. You can also use {{prog|urpmi}} to download the source.<br />
<br />
For example:<br />
<br />
<pre><br />
[camille@kenobi ~/rpmbuild]$ rpm -i /cooker/SRPMS/ktron-1.0.1-rosa2012.src.rpm <br />
[camille@kenobi ~/rpmbuild]$ ls -R * <br />
SRPMS:<br />
SPECS:<br />
ktron.spec<br />
SOURCES:<br />
ktron-1.0.1.tar.bz2<br />
RPMS:<br />
noarch/ i686/ i586/ i386/<br />
BUILD: <br />
</pre><br />
<br />
We see that rpm has installed in our RPM tree the source file {{file|ktron-1.0.1.tar.bz2}} and the spec file. Even before building a newer version of a package, it might be very interesting for you to rebuild the current package in order to understand how it is compiled and if it compiles. The magic command for doing this is {{prog|rpmbuild}} with the option {{cmd|buildall}}:<br />
<br />
<pre><br />
[camille@kenobi ~/rpmbuild]$ cd ~/rpmbuild/SPECS<br />
[camille@kenobi ~/rpmbuild]$ rpmbuild -ba ktron.spec<br />
[camille@kenobi ~/rpmbuild]$ ls -l ~/rpmbuild/RPMS/i586/ktron-1.0.1-rosa2012.i586.rpm<br />
[camille@kenobi ~/rpmbuild]$ ls -l ~/rpmbuild/SRPMS/ktron-1.0.1-rosa2012.src.rpm<br />
</pre><br />
<br />
If the build finished (it can last hours for some packages like kernels) without errors, you will get the binary rpm and the src rpm into your {{file|~/rpmbuild/RPMS/i586}} and {{file|~/rpmbuild/SRPMS/}} subdirectories respectively. If you want to install the binary rpm, you must act as 'root' which you can access to by typing {{cmd|su}} (and exit by typing {{cmd|exit}}). But in order to build an rpm, and to expand an src.rpm, you do not have to, and must not be root.<br />
<br />
The log of the build might be very long, and it's a good practice to store it for later browsing. You may use {{cmd|tee}} for that.<br />
<br />
In the {{file|~/rpmbuild/BUILD}} sub-directories you will usually access to the patched sources (if one or more patches were given in {{file|~/rpmbuild/SOURCES}}), to the binaries, compiled libraries, man pages etc. The spec file describes the source and patch files, how to build the package and how to install the package. <br />
<br />
Modifying {{file|src.rpm}} is not how existing packages are modified. ROSA sources do not store {{file|src.rpm}} files. It stores {{file|.spec}} files and the accompanying sources in a Git repository, and the {{file|src.rpm}} files are generated from them during the package build on the build system.<br />
<br />
=== From raw (tarball) sources ===<br />
For example, if you find an interesting program at [http://github.com/ github] or [http://sourceforge.net/ SourceForge], or created one on your own, you may want to make it available to all ROSA users. The best way to do that is to create a project in ABF, and create an RPM spec file that conforms to ROSA standards and guidelines.<br />
<br />
First, download the tarball with sources, and place it in the {{file|~/rpmbuild/SOURCES}} directory.<br />
<br />
==== Preliminary checks ====<br />
; License: Despite the prevalence of GPL licenses, there are still a number of non-GPL licenses in use today. Check the license of the software carefully to determine whether or not it may be incorporated in the distribution. We do not accept non-free software, but some exceptions exist for the club. Also, we cannot accept software that does not allow us to freely distribute it. Watch out for these programs. A list of licenses and acceptable software may be found on [[Licensing policy|ROSA Licensing Policy]]<br />
; Tarball Compression: To save efforts to maintain in the future, it is <b>recommended</b> to use the original tarball without any modifications. If sources are provided in various compression methods, we often choose {{file|.tar.bz2}}. Avoid compressing text format patches (as produced by {{prog|diff}} and the likes) and other configuration/scripts/etc. (text) files, as it usually saves very little space, while making harder to see the changes in Git diffs (which already uses some form of compression). <b>Note</b>: For <b>high-risk security-critical packages</b> we recommend that you <b>don't modify the original source distribution at all</b>, as it will change the checksum/signature. For these kinds of packages we recommend that you leave it in the original form, so that when someone runs {{prog|md5sum}}/{{prog|gpg}} on it, it will match the values as listed at the download location. One such example where this exception may apply would be <i>OpenSSH</i>.<br />
<br />
=== Inside the spec file ===<br />
Here we are. This is the important section of this document. The spec file contains all the information needed by rpm to:<br />
<br />
# compile the program and build source and binary rpms,<br />
# install, uninstall, and update the program on the final user's machine. <br />
<br />
The fact that these two types of information are combined into one single file may be quite confusing for the beginner. Actually, this is due to the source tar tree, which contains already this information. As installation procedure is extracted from the installation process generally run by make install into the source tree, both parts are tightly linked.<br />
<br />
In a nutshell, the spec file describes a "simulated" compilation and installation, tells rpm which files resulting from this installation are to be packed, and how to finally install these files onto the user's system. Commands there are executed using the /bin/sh shell, so things like {{cmd|[ -f configure.in ] && autoconf}} are valid.<br />
<br />
This part is not intended to explain in detail all the features of a spec file. The [http://rikers.org/rpmbook/ book Maximum RPM] (see Section 7) explains it in depth. All we are going to do here is quickly check all of the features used in one standard example ROSA spec file.<br />
<br />
This is an example from the cooker repository. You may also consider our [[Development/Packaging/Tools#Resources|template spec files]] to start one from scratch.<br />
<br />
As you build more and more RPMs,you will find that there are some options that we have not told you about. RPM is extremely extensible, so, finding out all of those is left as an exercise to the reader. It is always good practice to open up some spec files to take a look at them and see how they work.<br />
<br />
<pre><br />
Name: gif2png<br />
Summary: Tools for converting websites from using GIFs to using PNGs <br />
Version: 2.0.1 <br />
Release: 1<br />
Source0: http://www.tuxedo.org/~esr/gif2png/%{name}-%{version}.tar.bz2 <br />
Source1: %{name}-%{version}-rosa-addon.tar.bz2 <br />
Patch0: gif2png-2.0.1-bugfix.patch<br />
URL: http://www.tuxedo.org/~esr/gif2png/ <br />
<br />
Group: Applications/Multimedia <br />
License: MIT-like <br />
Requires: python <br />
<br />
%description<br />
Tools for converting GIFs to PNGs. The program gif2png converts GIF files<br />
to PNG files. The Python script web2png converts an entire web tree, also<br />
patching HTML pages to keep IMG SRC references correct.<br />
<br />
%prep <br />
%setup -q -a 1 <br />
%patch -p1 <br />
<br />
%build <br />
%configure2_5x<br />
%make<br />
<br />
%install<br />
%makeinstall_std<br />
<br />
%files <br />
%defattr(0755,root,root) <br />
%doc README NEWS COPYING AUTHORS <br />
%{_mandir}/man1/gif2png.1*<br />
%{_mandir}/man1/web2png.1*<br />
%{_bindir}/gif2png <br />
%{_bindir}/web2png <br />
<br />
# Omit %changelog when you're creating RPM packages for ROSA! This is only an example!<br />
%changelog <br />
* Mon Nov 02 1999 Camille Begnis <camille@mandrakesoft.com> 2.0.1-rosa2012<br />
- Upgraded to 2.0.1 <br />
<br />
* Mon Oct 25 1999 Camille Begnis <camille@mandrakesoft.com> 2.0.0-rosa2012<br />
- Specfile adaptations for Mandrake<br />
- add python requirement<br />
- gz to bz2 compression<br />
</pre><br />
<br />
Let's then analyze in detail each line of this file:<br />
<br />
Be careful, a % at the beginning of a line may tell different things :<br />
<br />
* the beginning of a section (prep, build, install, files)<br />
* a built-in shell script macro (setup, patch)<br />
* a directive used by a special section (defattr, doc, ...) <br />
<br />
<br />
==== Header section ====<br />
The header section should contain standard name, version and release tags:<br />
<br />
<pre><br />
Name: gif2png<br />
Version: 2.0.1<br />
Release: 1<br />
</pre><br />
<br />
These three lines automatically define macros that may be used in many following sections of the spec file, named {{macro|%{name} }}, {{macro|%{version} }} and {{macro|%{release} }}. Note that some packages can have obsolete call to {{macro|%mkrel}} macro which simply returns its argument in ROSA.<br />
<br />
The name of the package as used in the package's name and in the package database on the user's machine. This is the string users will see in the package manager as a name of your package.<br />
<br />
There are also some tags that you might want to know about, but which are not in the spec file example. There are some that you might encounter. It is not expected that you remember all of this if you just started building rpms, but after some time, this list makes good reference!<br />
<br />
At this point we must explain how the name of a package is formed. It is important to always respect this standard in order to make your work understandable to others.<br />
<br />
* A binary package is named as: name-version-release-rosa2012.arch.rpm (rosa2012 designates DISTTAG and DISTEPOCH and is automatically added by rpmbuild)<br />
* A source package is named as: name-version-release.src.rpm (i.e. {{pkg|gif2png-2.0.1.src.rpm}} in our example) <br />
<br />
The name is generally chosen to be the name of the main binary of the package, though with adequate reason you can get away with another name.<br />
<br />
The version is the number from the unpatched sources. It is the version number in the name of the original archive file: name-version.tar.gz.<br />
<br />
The release is a number which is incremented at each new build of the package. This may be due to a patch applied to the sources, a modification to the spec file, the addition of an icon, etc.<br />
<br />
The name of the package is automatically generated from Release:, Version:, and Name: fields.<br />
<br />
<pre><br />
Summary: tools for converting websites from using GIFs to using PNGs<br />
</pre><br />
<br />
This line is a one-liner of the package description. It should be less than 80 characters long (see [[RPM spec file syntax]]).<br />
<br />
<pre><br />
Source0: http://www.tuxedo.org/~esr/gif2png/%{name}-%{version}.tar.bz2 <br />
</pre><br />
<br />
This line tells rpm what source file to use for building this package. Note that the filename is preceded by a complete URL (which is optional) pointing to the site where the original source is available; rpm will remove the url, keep the filename only, and search in the {{file|SOURCES}} directory. Although we say that the complete URL is optional, it is highly recommended so people will know where to find new sources should they take a liking to upgrading the source and do a recompilation. This will also allow automated tools like [http://upstream-tracker.org/updates/rosa/main/ Updates Tracker] to automatically check for new versions.<br />
<br />
When there is more than one source file, use other lines with Source1: ..., then Source2: ..., etc.<br />
<br />
<pre><br />
Patch0: gif2png-2.0.1-bugfix.patch<br />
</pre><br />
<br />
Two reasons for this optional tag:<br />
<br />
# You fixed a bug on the program sources. So you [[Rpmbuild_and_git|generated a patch file]] to be applied to the sources before compilation.<br />
# You've been warned of the existence of a patch for your software's version somewhere on the net and downloaded it, or you [[Rpmbuild_and_git|cherry-picked it]].<br />
<br />
{{message|The patch file must be placed into the {{file|SOURCES}} directory; as for the sources, there can be several patches, they will be named Patch1, Patch2, etc.}}<br />
<br />
The patches you list under Patch0:-like sections will '''not''' be applied automatically; see below how to apply them.<br />
<br />
<pre><br />
URL: http://www.tuxedo.org/~esr/gif2png/<br />
</pre><br />
<br />
This line (optional but highly recommended) points to the home page of the program.<br />
<br />
<pre><br />
Group: Multimedia<br />
</pre><br />
<br />
This is to tell {{prog|rpm}} in which part of the general package tree to place this package. This feature is used with package managers front-ends such as rpmdrake.<br />
<br />
The complete group structure to use, which may be different from the one ROSA uses, can be found on the page [[Packaging group|Packaging Groups]]. It is mandatory to follow it, otherwise your package will mess with the other ones, in the package tree selection of the system installer, or in package manager front-ends.<br />
<br />
<br />
<pre><br />
License: MIT-like<br />
</pre><br />
<br />
This tag (superceding Copyright) defines the license chosen by the copyright holder that will apply to the software being packed. In most cases it is GPL. See [[Licensing policy|Licensing Policy]] for complete valid licenses list<br />
<br />
<pre><br />
Requires: python<br />
</pre><br />
<br />
This line was added because one of the programs included in the package is a python script. It then needs {{prog|python}} to be executed. You can put optional minimum (or equal) version, for example: Requires: python >= 2.7.<br />
<br />
If your package contains executable files linked against C or C++ libraries, such "requires" are generated by {{prog|rpmbuild}} automatically.<br />
<br />
<pre><br />
%description<br />
Tools for converting GIFs to PNGs. The program gif2png converts GIF files<br />
to PNG files. The Python script web2png converts an entire web tree, also<br />
patching HTML pages to keep IMG SRC references correct.<br />
</pre><br />
<br />
This is a quite special tag inside the header of the spec file, because it is a complete text made up of various lines and paragraphs, if needed. It contains the full description of the software being installed in order to help the user to decide whether he wants to install the package or not.<br />
<br />
You may be asking yourself at this point: "And what about translations?" Actually, to improve readability of spec files, translations of summary and description tags are stored in a special file called {{file|<package>.po}}.<br />
<br />
This method implies that all text inside a .spec file is written in English. With the exception, however, of packages intended for a particular language (ispell-de for example). In that case it is recommended to have the text in two languages: English and in the language of that particular package. You will use special tags for this: Summary(de): .. and {{macro|%description -l de}}.<br />
<br />
==== Prep section ====<br />
<pre><br />
%prep <br />
%setup -q -a 1<br />
%patch0 -p1<br />
</pre><br />
<br />
Into this section, is written the first script being executed by rpm. Its role is to:<br />
<br />
* create the top-level build directory (into BUILD),<br />
* unpack the original sources into the build directory,<br />
* apply optional patches to the sources. <br />
<br />
It may then be followed by any command the packager wants in order to get the sources into a ready-to-build state.<br />
<br />
<pre><br />
%setup -q -a 1 <br />
</pre><br />
<br />
This is a buit-in script macro which<br />
<br />
* cd's into the build tree,<br />
* extract the source(s) (quietly, -q)<br />
* change ownership and permissions of source files. <br />
<br />
By default it extracts the first source; you have to use parameters for any other sources, in our example <tt>-a 1</tt> tells that we also want the extraction from source number 1.<br />
<br />
There are other interesting switches which can be used with %setup macro:<br />
<br />
* -c name - switch -c wrote that upper directory is created first; then cd into this directory and then unpack Source0. This is useful if an archive is extracted without a parent directory.<br />
* -D - does not delete the directory before unpacking. This is only useful if you have more than one setup macro. It should only be used in setup macros after the first one (but never in the first one).<br />
* -T - this option overrides the default action of untarring the Source and requires a -b 0 or -a 0 to get the main source file untarred. You need this when there are secondary sources.<br />
* -n name - if the name of the rpm is something other than what the Source unpacks to, use this switch. For example: if the rpm name is program-version-revision and the Source unpacks to the program-version-date, the rpm build process will not be able to cd into the directory program-version, so use -n program-version-date, so rpm will know the new directory in which to continue.<br />
<br />
<pre><br />
%patch0 -p1<br />
</pre><br />
<br />
The macro responsible for applying the patch to the sources; its parameter "-p<num>" is passed to the patch program. Imagine if you had another patch declared Patch1: .. in the header section, you would add another line: {{macro|%patch1 -p1}}. Adding a {{cmd|-b .your_suffix}} would also be nice, as you can let others know what your patch does, or who did the patch. For example, if Fred did the patch, then he could do {{macro|%patch -p1 -b .fred}}, or if Barney did the patch then it could be {{macro|%patch -p1 -b .barney}}<br />
<br />
<br />
==== Build section ====<br />
<pre><br />
%build <br />
</pre><br />
<br />
This section will contain the script responsible for the actual build of the software.<br />
<br />
It consists of the commands being issued when building a package from an untarred source tree.<br />
<br />
<pre><br />
%configure2_5x<br />
</pre><br />
<br />
This is the line used for configuring autoconf'ed sources. {{macro|%configure}} issues a {{cmd|./configure}} with many add-ons such as <pre>export CFLAGS="$RPM_OPT_FLAGS"</pre> before the configure, and options such as <pre>i586-mandrake-linux --prefix=/usr --datadir=/usr/share</pre> etc.<br />
<br />
Sometimes these arguments are not supported by the configure script. In such case, you have to discover the reason, and issue the {{cmd|./configure}} with appropriate parameters. Give the target platform to the configure call, if supported, with {{macro|%{''target''platform} }}; of course, specification of an architecture must be avoided in specfiles; on ix86, this will expand to i586-mandrake-linux, as shown in the example above.<br />
<br />
{{message|You will need the {{pkg|libtool}} package to use {{macro|%configure}} with packages building shared libraries.}}<br />
<br />
When building, and when testing your package, you should verify that the target host is actually an i586 ; in particular, when compiling on a higher processor type, the default behaviour of the configure script is to discover your processor, and optimize for it. The target of the {{macro|%configure}} macro is to avoid this behaviour.<br />
<br />
<pre><br />
%make<br />
</pre><br />
<br />
This is a simple macro that basically performs a make with the appropriate multiprocessor parameter {{cmd|-j<num>}} for your system.<br />
<br />
For sources using xmkmf, you should replace the next make with:<br />
<br />
<pre><br />
make CDEBUGFLAGS="$RPM_OPT_FLAGS" CXXDEBUGFLAGS="$RPM_OPT_FLAGS" <br />
</pre><br />
<br />
For other packages, in many (but not all) cases a simple make will do.<br />
<br />
==== Install section ====<br />
<pre><br />
%install <br />
</pre><br />
<br />
This section will contain the script responsible for actually installing the package in the simulation installation dir.: {{file|<nowiki>%{buildroot}</nowiki>}}.<br />
<br />
It will contain all commands necessary to make the software ready to run on the user's system.<br />
<br />
<pre><br />
%makeinstall_std<br />
</pre><br />
<br />
This line finally installs the software into the simulation installation directory for autoconf'ed sources. This macro will expand to<br />
<br />
<pre>make install DESTDIR=%buildroot</pre><br />
<br />
To save both disk space and download time, ROSA uses xz to compress man- and info-pages. However, this aspect is handled directly by the ROSA custom rpm program.<br />
<br />
To install additional files with proper permissions, the {{cmd|install}} command comes handy.<br />
<br />
In this section, you must also remove from the {{macro|%buildroot}} the files you're not going to install. Here's an excerpt from a spec file:<br />
<br />
# Don't install READMEs twice<br />
rm -f %{buildroot}%{perl_vendorlib}/urpm/README*<br />
<br />
After the {{macro|%build}} section has completed its execution, '''only''' the files that will be installed to the system, should remain. All other files '''MUST''' be removed.<br />
<br />
Now the files to be ready to be packed.<br />
<br />
==== Clean section ====<br />
<br />
'''DO NOT''' add {{macro|%clean}} into your ROSA packages. Use {{cmd|rpmbuild --clean ...}} option instead.<br />
<br />
==== Files section ====<br />
<pre><br />
%files <br />
</pre><br />
<br />
This section consists of a list of files that will be installed onto a system when the user installs the package. These files are picked from our simulation directory tree where the package was "installed" during the build. Each file from that install directory should be listed ''exactly once'' under the {{macro|%files}} section.<br />
<br />
The file list must be written by hand in the spec file. It may be constructed by listing all files created by rpm in the build directory tree. In order to do that, issue a {{cmd|rpmbuild -bi mypackage.spec}} in order to stop the building process just after the simulated install. Then, look in the simulated installation directory, {{file|~/rpmbuild/BUILDROOT/gif2png}} in our case, to see which files you want to put in your package (most of the time, you will put them all).<br />
<br />
Note that you should never use find to build a list of files to include but explicitly list all files (this will show up bugs in new versions). The only exceptions is for locales for which you should use {{macro|%find_lang %{name} }} in the {{macro|%install}} section and replace {{macro|%files}} by {{macro|%files -f %{name}.lang}} (see [[#More_macros|Appendix B]]).<br />
<br />
{{message|About directory structure : The files being installed by your package "should" follow the FHS recommendations at http://www.pathname.com/fhs }}<br />
<br />
<pre><br />
%defattr(0755,root,root,-)<br />
</pre><br />
<br />
This tag defines the attributes to be applied to each file being copied to the user's system. The four arguments given mean:<br />
<br />
* -: all the attributes for regular files are remaining unchanged,<br />
* root: the owner of the file is root,<br />
* root: the group of the file is root,<br />
* 0755: the attributes applied to all directories owned by this package are 0755 ( rwxr-xr-x ).<br />
<br />
This line can be omitted, then the default values (-,root,root,-) will be used.<br />
<br />
<pre><br />
%doc README NEWS COPYING AUTHORS<br />
</pre><br />
<br />
The special tag {{macro|%doc}} designates files being part of the documentation of the package. The said files will be placed in {{file|/usr/share/doc/gif2png-2.0.1/}}. This directory will be also automatically created. Files specified by {{macro|%doc}} are relative to your untarred source (not install!) directory in {{file|BUILD}}.<br />
<br />
<pre><br />
%{_mandir}/man1/gif2png.1*<br />
%{_mandir}/man1/web2png.1*<br />
</pre><br />
<br />
It is recommended to list here also each man or info file separately.<br />
<br />
Also you may wonder why gif2png.1* was used instead of gif2png.1.xz. This is done to decouple manpage archiving type from the file name in the spec, and to preserve compatibility with other systems that could use gzip compression instead. If you find such references to any specific kind of compression in spec files, change them to a wildcard. Most of the time you can even use {{macro|%{_mandir}/man1/*}}, this will take all the files it can find.<br />
<br />
<pre><br />
%{_bindir}/gif2png<br />
%{_bindir}/web2png<br />
</pre><br />
<br />
As you can see, you have macros for every kind of path you need. Here are the most useful ones (look at the file {{file|/usr/lib/rpm/macros}} and {{file|/usr/lib/rpm/macros.d}} and {{file|/etc/rpm/macros.d}} directories) : {{macro|%{_prefix} }}, {{macro|%{_bindir} }}, {{macro|%{_sbindir} }}, {{macro|%{_datadir} }}, {{macro|%{_libdir} }}, {{macro|%{_sysconfdir} }}, {{macro|%{_mandir} }}, {{macro|%{_infodir} }}. For games, use {{macro|%{_gamesbindir} }} and {{macro|%{_gamesdatadir} }}.<br />
<br />
There are also subsystem-specific macros useful when packaging application from a certain software stack. Such macros available in ROSA are described in appropriate packaging policies on this wiki - for example, macros useful when packaging KDE applications can be found at the [[KDE_SC_4_packaging_policies|KDE4 Packaging Policy]] page.<br />
<br />
==== Changelog section ====<br />
<br />
'''NOTE''': This is just a general information on {{macro|changelog}} section. You '''MUST NOT''' add it to your spec file, as it will be automatically generated from commit messages in the revision control system.<br />
<br />
===== Changelogs in general =====<br />
<br />
<pre><br />
%changelog <br />
</pre><br />
<br />
This section is to keep track of different changes made to the package. Every new release build of the package must correspond to a paragraph in this section as well as an increase in the release number (if not in the version number). The structure of these paragraphs have to be respected as following:<br />
<br />
<pre><br />
* Mon Nov 02 1999 Camille Begnis <camille@mandrakesoft.com> 2.0.1-1<br />
</pre><br />
<br />
* The first line of the paragraph begins with * and, in order, each one separated by a space:<br />
* three letters for the day of the week,<br />
* three letters for the month,<br />
* two figures for the day of the month,<br />
* four figures for the year,<br />
* First name of the packager,<br />
* Last name of the packager,<br />
* e-mail of the packager between <>.<br />
* version and release of current modifs. <br />
<br />
<pre><br />
- Upgraded to 2.0.1<br />
</pre><br />
<br />
Then follows one line per modification applied to the package beginning with a -.<br />
<br />
These are examples:<br />
<br />
<pre><br />
- spec file stolen from korganizer. <br />
- last snapshot before release <br />
- ROSA adaptations. <br />
- Fix bug in /etc/zsh use USERNAME instead of USER. <br />
- Remove petit bouchon which annoys other players. <br />
- Improve /etc/z* to source the /etc/profile.d/ files. <br />
- fix typo in examples directory name <br />
- fixed QT libs version requirements <br />
- add patch to hab>don't modify the original source distribution at allndle Earl Grey tea <br />
</pre><br />
<br />
Note that by default only entries younger than 1 year will be preserved in the built package. To change this behaviour modify the value of {{macro|%_changelog_truncate}}<br />
<br />
===== Commit logs =====<br />
<br />
The information in this section is ''automatically generated from git commit logs''. Each line of the log starting with ''LOG'' becomes a line that begins with a dash (it's added automatically), and describes the matter of the change brought by this commit (see examples above). The commits will be automatically grouped by your name and e-mail address associated with your ABF account entry.<br />
<br />
To make a line not appear in the log, add "<code>SILENT: </code>" at the beginning of it. Blank linkes are also ignored.<br />
<br />
=== The build ===<br />
Our spec file is finally complete. Take a long breath, sit down and type {{cmd|rpmbuild -ba mypackage.spec}}<br />
<br />
You may also add the {{cmd|--clean}} option which cleans the {{file|BUILD}} directory after package building completes. This is useful if you have little disk space.<br />
<br />
There are then two possibilities for the last line of your process:<br />
<br />
* 0.01% probabilities: + exit 0<br />
* 99.99% probabilities for other cases. <br />
<br />
You are in the second case? Congratulations you passed the test, you are not an alien.<br />
<br />
Good luck, so long, have a look to rpm building options ({{cmd|man rpmbuild}} ) to debug your work, look at other persons' specfiles, etc..<br />
<br />
There is a very clean way to build packages: use {{cmd|rpmbuild -bs --rmspec --rmsource}} (in order to remove anything from the original build) and then do a {{cmd|rpmbuild --rebuild}}.<br />
<br />
<br />
=== Optimize the build ===<br />
When you launch the command to build your package, you certainly noticed message like "{{cmd|foo-devel is necessary for foo2}}".<br />
<br />
This means that it needs informations from other packages used for development (usually files named {{file|foo.h}}). If you don't have these, compilation will stop or features will be missing in your package.<br />
<br />
The place where all official packages are built (build system at ROSA) have a lot of these devel packages preinstalled. If one is not declared in your SPEC file and is mandatory, the package will be built anyway on the cluster. It will work, but the lack of this information prevents building on machines missing the devel package, making debugging/upgrading more difficult.<br />
<br />
Look at the website of the package, it will give information about needed components (but not always)<br />
<br />
An idea to hunt down these "missing BuildRequires" is to start packaging with only basics devel packages installed :<br />
<br />
* {{pkg|glibc-devel}}<br />
* {{pkg|libncurses5-devel}}<br />
* {{pkg|libstdc++6-devel}}<br />
<br />
After that, only install the package's relative devel package that is asked for by the rpm build command.<br />
<br />
When launching the build, watch for "checking for.." messages.<br />
<br />
If you see something like "checking for foo... foo.h not found", this means that a header needed has not been found on your system.<br />
Search for the devel package containing "foo.h", but be careful: you can find more than one package containing what you seek. So choose the more obvious package. Don't choose a network related package when you build a sound application (for example).<br />
<br />
Then install it on your system, and don't forget to add its name in the BuildRequires section of your {{file|SPEC}} file.<br />
<br />
Missing headers can also be found during compilation itself. If it stops, check for others missing "{{file|foo.h}}" and apply the same recipe.<br />
<br />
If you want to install all BuildRequires of a ready rpm package (for testing purposes, for instance), issue {{cmd|urpmi --buildrequires package.rpm}}.<br />
<br />
== Testing an RPM ==<br />
<br />
=== Basic tests ===<br />
The first steps to perform are:<br />
<br />
* Are the rpms created in the corresponding directories with the correct names? (into {{file|~/rpmbuild/SRPMS/}} and {{file|~/rpmbuild/RPMS/i586/}})<br />
* Is the information obtained from issuing the command {{cmd|rpm -qlivp --changelog mypackage.(src.)rpm}} correct?<br />
<br />
=== Linting the package ===<br />
Next, you '''MUST''' use [[Rpmlint]] which will test various things on the package. Before running {{cmd|rpmlint}}, make sure you have {{pkg|rpmlint-mandriva-policy}} package installed which contains rpmlint configuration for ROSA. If {{cmd|rpmlint}} reports errors, the package will be rejected from the distribution, and if there are too many warnings of certain types, it will not pass either. But even if the warnings do not make your package fail, you should pay attention to them, and try to fix as many as possible.<br />
<br />
To run the check, type {{cmd|rpmlint mypackage.<archtype>.rpm}} and a report on the specified package will be issued. For more precision, use the {{cmd|-i}} switch. You should check the {{file|rpm}} and the {{file|src.rpm}}. More information on the errors, and on how to fix them can be found on [[Problems and issues with packaging]].<br />
<br />
=== Install test ===<br />
On any machine - but preferably on a different one than that used for compilation - do an upgrade or an install, and then check:<br />
<br />
* Are all the expected files created at their expected places with the expected rights and owners?<br />
* Are all the installation modifications (if any) effective?<br />
* Are all binaries executable, and is the documentation accessible to the intended users? <br />
<br />
Perfectionists should try various different installs and uninstalls to check whether all expected features are implemented correctly, for example without required packages.<br />
<br />
If all of these tests are passed successfully, you are almost done, and should go to the last step of the process: submitting packages.<br />
<br />
<br />
== Something's going wrong? ==<br />
Well, it appears that you have been reading this HowTo, which is a good beginning. If you couldn't find your answer right here, you should try in the given order:<br />
<br />
# The official RPM-HOWTO (installed along with the rpm program on your system);<br />
# The book from Red Hat "Maximum RPM", which is available at http://www.redhat.com/docs/books/max-rpm/max-rpm-html/;<br />
# Take a look at how spec files for the similar packages are written;<br />
# Post a question in the development mailing list you subscribed to when you started to participate in ROSA project.<br />
<br />
If you feel that the information you found may be useful to others, in the scope of that document, feel free to submit your proposal to the maintainer of that document.<br />
<br />
== Of Pre- and Post-installation scripts ==<br />
=== Basics ===<br />
The RPM package is in fact a bit more than a simple archive containing files to be expanded in specific directories of the host client system.<br />
<br />
The system offers to the programmer a great feature: pre- and post-installation scripts. They allow the packager to write a piece of code which will be executed on the client machine while installing or erasing the package.<br />
<br />
These scripts are made of any sh valid commands. There are four of them:<br />
<br />
There are certain caveats about these scripts which you should take into account. Number one, each must fit inside a 8192 buffer, and number two, they should be non-interactive. Anything which requires manual input from the user is wrong, as this will break non-interactive RPM installation procedures.<br />
<br />
* {{macro|%pre}} - This script is executed just before the package is installed on the system.<br />
* {{macro|%post}} - This script is executed just after the package is installed on the system.<br />
* {{macro|%preun}} - This script is executed just before the package is uninstalled from the system.<br />
* {{macro|%postun}} - This script is executed just after the package is uninstalled on the system.<br />
<br />
The scope of such scripts may be very large, and they have to be designed with much care not to harm the host system. One has to remember that these scripts will be run as root... They correspond to the tasks a system administrator would have to accomplish when installing a new program on a system. For example:<br />
<br />
* Add a {{prog|cron}} job running the program at fixed intervals<br />
* Run {{prog|chkconfig}} to run the daemon at boot time<br />
* ...<br />
<br />
<br />
=== Dealing with upgrades ===<br />
The fact that a package may be upgraded, and not simply installed or removed, makes the thing a little bit tougher... The problem is that the {{macro|%postun}} script of the update is run after the {{macro|%post}} of the old version. So all {{macro|%post}} stuff is lost...<br />
<br />
It is often useful to ensure that an action occurs only during an install and not during an upgrade. Likewise for an action that only occurs during an uninstall and not during an upgrade. RPM's mechanism for dealing with this is the argument that is passed to the {{macro|%pre}}, {{macro|%preun}}, {{macro|%post}} and {{macro|%postun}} scripts by default. <br />
<br />
This argument indicates the number of instances of this RPM that will be installed on the machine after the current script has completed. For example, if a new package is installed then 1 will be passed to {{macro|%pre}} and 1 passed to {{macro|%post}}. When the package is upgraded, 2 will be passed to {{macro|%pre}} of the new RPM, 2 will be passed to {{macro|%post}} of the new RPM, 1 will be passed to {{macro|%preun}} of the old RPM and 1 will be passed to {{macro|%postun}} of the old package.<br />
<br />
<br />
{| border="1"<br />
|+ align="bottom" style="font-size: 10px; font-weight: bold;" | Table A-1. Value of the parameter passed to pre and post scripts<br />
! style="background:#efefef;" | Parameter \ Script<br />
! style="background:#efefef;" | %pre<br />
! style="background:#efefef;" | %post<br />
! style="background:#efefef;" | %preun<br />
! style="background:#efefef;" | %postun<br />
|-<br />
| for a first time install || 1 || 1 || N/C || N/C<br />
|-<br />
| for an upgrade || 2 || 2 || 1 || 1<br />
|-<br />
| for a removal || N/C || N/C || 0 || 0<br />
|}<br />
<br />
This will allow the programmer to distinguish different attitudes of his scripts depending on the operation: install or upgrade.<br />
<br />
* For install scripts ( {{macro|%post}}, {{macro|%pre}} ) check if $1 is equal to "1" then it is a first time install, not an update.<br />
* For uninstall scripts ( {{macro|%postun}}, {{macro|%preun}} ) check if $1 is equal to "0", if yes then it is a full removal; if not it is either an upgrade or an install --force of the same package.<br />
<br />
To test this argument, the following 'if' statement is used:<br />
<br />
<pre><br />
%postun<br />
if [ $1 = 0 ]; then<br />
// Do stuff specific to uninstalls<br />
fi<br />
if [ $1 = 1 ]; then<br />
// Do stuff specific to upgrades<br />
fi<br />
</pre><br />
<br />
A single test is therefore enough, to call the right action at the right time.<br />
<br />
<br />
== Filetriggers ==<br />
In ROSA, [[rpm filetriggers]] are used to remove the burden of the repetitive tasks like "%post -p /sbin/ldconfig" or "%update_menus".<br />
<br />
<br />
== More macros ==<br />
When building RPM's for ROSA, you have more macros to simplify the specfile.<br />
<br />
* Handling internationalization cleanly. The best way is not to enter by hand the {{file|.mo}} files that usually are in {{file|/usr/share/locale/..}}, but to use a special macro in the {{macro|%install}} section, which will fill up a special file for that:<br />
<br />
<pre><br />
%find_lang %{name}<br />
</pre><br />
<br />
Then you will use the file in the file list:<br />
<br />
<pre><br />
%files -f %{name}.lang<br />
</pre><br />
<br />
* Build macros. The build macros {{macro|%configure}} and {{macro|%makeinstall}} are quite big at the present time. They specify the prefix, but also every common directory (such as bindir, datadir, and so on); in that respect, they work flawlessly with small and medium sized packages, but always need some attention for the rest. The macro {{macro|%make}} performs the make command with appropriate {{cmd|-j<num>}} option to scale well with multiprocessors. If you need to call manually the {{prog|./configure}} script, remember to NEVER hardcode the architecture; the macro {{macro|%{''target''platform} }} is made for that purpose (or even {{macro|%{''target''cpu} }}, if necessary).<br />
* Building servers. To build safer servers, we use a specific macro, {{macro|%serverbuild}}, to be used before the actual build occurs. This allows for safer optimization flags. The {{macro|%build}} section will often look like:<br />
<br />
<pre><br />
%build<br />
%serverbuild<br />
%configure2_5x<br />
%make<br />
</pre><br />
<br />
With 2012 ROSA release we have added a hardened macro which is called {{macro|%serverbuild_hardened}}. This macro exports -fPIE to the CFLAGS and -Wl,-z,now -pie to the LDFLAGS.<br />
This macro is recomended to provide better security by using full RELRO and PIE.<br />
<br />
<pre><br />
%build<br />
%serverbuild_hardened<br />
%configure2_5x<br />
%make<br />
</pre><br />
<br />
* Initscript macros. When you install a package which will provide it's own initscript (the files in the directory {{file|/etc/init.d}} ), it needs to be added through a call which looks like {{cmd|chkconfig --add ..}}, but not in the case of upgrades, and it needs to be restarted if already running; when uninstalling, similar (opposite) things must be done; we have specific macros to do that without a glitch:<br />
<br />
<pre><br />
%post<br />
%_post_service <initscript-name><br />
<br />
%preun<br />
%_preun_service <initscript-name><br />
</pre><br />
<br />
* Handling ghostfiles. Mostly with games, sometimes packages use a varying file which may even not be present. That's where ghostfiles are useful. Here's an example:<br />
<br />
<pre><br />
%install<br />
<br />
(...)<br />
<br />
mkdir -p %{buildroot}/var/lib/games<br />
touch %{buildroot}/var/lib/games/powermanga.hi<br />
<br />
%post<br />
%create_ghostfile /var/lib/games/powermanga.hi root games 664<br />
<br />
(...)<br />
<br />
%files<br />
%attr(664, root, games) %ghost /var/lib/games/powermanga.hi<br />
</pre><br />
<br />
The {{macro|%create_ghostfile}} macro will expand to:<br />
<br />
<pre><br />
if [ ! -f /var/lib/games/powermanga.hi ]; then <br />
touch /var/lib/games/powermanga.hi<br />
chown root.games /var/lib/games/powermanga.hi<br />
chmod 664 /var/lib/games/powermanga.hi<br />
fi <br />
</pre><br />
<br />
* Scrollkeeper database update: scrollkeeper database (used to index docbook documentation) should be updated when installing an {{file|.omf}} file like this:<br />
<br />
<pre><br />
...<br />
%post<br />
%update_scrollkeeper<br />
<br />
%postun<br />
%clean_scrollkeeper<br />
</pre><br />
<br />
== Interaction with urpmi and rpmdrake ==<br />
Sometimes it's necessary to warn the user about some particular care that should be taken when upgrading or installing a specific version of a package. {{pkg|rpmdrake-2.1.3}} and above supports this: it searches in rpms for text files named {{file|README.install.urpmi}}, {{file|README.update.urpmi}} or {{file|README.urpmi}}, and displays them.<br />
<br />
{{file|README.install.urpmi}} is displayed only for installed packages; {{file|README.update.urpmi}} only for upgraded packages; {{file|README.urpmi}} is displayed in both cases.<br />
<br />
<br />
== Alternative : checkinstall ==<br />
A very easy way to build RPMs for personal use is to install the checkinstall package; compile from source as usual (./configure && make && sudo make install), but just replace the {{cmd|make install}} step by {{cmd|checkinstall}}. This automates building an RPM, and is very simple to use. The advantage is that you don't ever have to bypass the package manager when compiling from source, and that you can remove your package completely by a standard rpm uninstallation procedure. (However, it's probably A Good Idea to build RPMs "properly" as described above, if you intend to distribute them to others.)<br />
<br />
== Related links ==<br />
* [[Packaging group|Packaging Groups]]<br />
* [[Licensing policy|ROSA Licensing policy]]<br />
<br />
<br />
== External links ==<br />
* [http://www-106.ibm.com/developerworks/library/l-rpm1/ IBM article on rpm building]<br />
* [http://www.redhat.com/magazine/002dec04/features/betterliving-part2/ A redhat magazine article on rpm building]<br />
* [http://www.gurulabs.com/GURULABS-RPM-LAB/GURULABS-RPM-GUIDE-v1.0.PDF Pdf tutorial on rpm building made by GuruLabs]<br />
* [http://docs.fedoraproject.org/drafts/rpm-guide-en/ Red Hat RPM Guide, hosted on fedoraproject.org]<br />
<br />
<hr><br />
<br />
{{message|This HowTo is based on the [http://wiki.mandriva.com/en/Mandriva_RPM_HOWTO Mandriva RPM Packaging Tutorial].}}<br />
<br />
[[Category:Package Management]]<br />
[[Category:Packaging Guidelines]]<br />
[[Category:ROSA Developer Tools]]<br />
<br />
[[ru:Основы RPM]]</div>Domtheohttp://wiki.rosalab.com/en/index.php?title=ROSA_Enterprise_Desktop_X1_(Marathon)&diff=8266ROSA Enterprise Desktop X1 (Marathon)2014-04-14T06:47:50Z<p>Domtheo: </p>
<hr />
<div><div style="color: #34A4FA; font-style:normal; font-size: 3em; font-weight: bold; text-align: center;">'''ROSA Enterprise Desktop X1 (Marathon)'''</div><br />
<br /><br />
'''ROSA Enterprise Desktop X1 (Marathon)''' is a LTS (long time support) release with guaranteed security and software updates for 5 years. Based on ROSA Marathon 2012 repositories with lots of improvements and updates. It is recommended for Enterprise, SMB and SOHO which do not need the "bleeding edge" technology, but require stable software and ability to work for a long time without reinstalling the system. This is the first release completely built using the ABF system.<br />
[http://digiadvertise.wordpress.com/2014/04/07/jasa-seo-di-jakarta Jasa seo] - [http://digiadvertise.wordpress.com/2014/04/07/jasa-seo-di-jakarta Jasa seo jakarta]<br />
<br />
You can find additional information about ROSA Enterprise Desktop X1 (Marathon) in its [[Tour_ROSA Marathon 2012| tour]] and some information about known issues and workarounds at the [[Errata_ROSA_Marathon_2012|Errata page]].<br />
<br />
<gallery align="center"><br />
File:R2012-Sss2.png | Desktop<br />
File:R2012-Sss1.png | SimpleWelcome<br />
File:R2012-Sss3.png | ROMP & Gwenview<br />
File:R2012-Sss4.png | StackFolder<br />
File:R2012-Sss5.png | Klook<br />
</gallery><br />
<br />
<hr><br />
<br />
[[ROSA Marathon X1|ROSA Enterprise Desktop X1 (Marathon) Release Notes]]<br />
<br />
[[ROSA Marathon 2012 Overview| ROSA Enterprise Desktop X1 (Marathon) Overview]]<br />
<br />
[[Errata ROSA Marathon 2012|Errata ROSA Enterprise Desktop X1 (Marathon)]]<br />
<br />
[[Upgrade systems]]<br />
<br />
[[Category:ROSA Marathon 2012]]<br />
<br />
[[ru:ROSA Marathon 2012]]<br />
[[it:ROSA Marathon 2012]]</div>Domtheo