Advanced Package Tool (APT) for SLES
While SuSE provides YaST as a toolset for maintaining packages on a SLES,
I find it difficult to automate package Selection, especially for adding and
removing packages and their dependencies from shell-scripts. I am confident
that autoyast can do all the things that I need, but it is badly documented
and working for a university lab with restricted funds, we could not afford
to have SuSE/Novell consultants come have it do for us.
Anyway, APT is the method of choice most debian-variants and a growing
number of RPM-based distributions as well. Even for the SuSE Professional
line exists a well documented port (see the 'APT for SuSE HowTo').
I am not the only one that uses apt on SLES. See below for other sources:
- a very good writeup by Stian Soiland that aided me greatly when getting apt to work in our network.
- YAM, a tool by Dag
Wieers to maintain the Repository with packages from varied other sources.
in order to run apt on SLES you need the following:
- SLES license (username/password to get SLES patches, you need at least a maintenance license to these)
- A web server that you are allowed to configure. The following documentation
asumes that you create a virtual host apt.your-domain.com, to access the repository. This need not be a SLES box.
- The ISO images of SLES9,
downloaded from Novell. If have them in a place other than /tmp/sles9_images you will have to change the
- about 9 GByte space on the filesystem that contains /src/www/vhosts. If you do not have the nessecary
space you should either change the create_apt_rep.sh and the update_sles9.sh scripts or make it a
symlink to an sufficiently sized filesystem.
Also, since the SLES is an enterprise product of Novell, this document
asumes that you are somewhat proficient with UNIX/Linux system administration
tasks, since you are unlikely to have even heard about SLES if
you are not somewhat familiar with Linux. But if you do not
understand things as written feel free to ask for clarification
Installing APT on SLES
- install the apt-libs
packages on each SLES box that you want to maintain with apt.
I build apt without the documentation set, as it would have required
to installa a complete teTex toolchain on my sles build machine. To
change that is on my TODO list.
- As the SLES packages are not publicly avaliable, you have to build your
own repository. The following need only be done on one machine in your
network. If it is a SLES box, install the
It need not be SLES box, but if it is not, you neet to get the apt-server
package for its distribution. And you need to download the create_apt_rep.sh script.
That script is also included in my version of the apt-server package and asumes
quite a lot about the directory layout of the server. If it is not a SuSE
box, or probably not even if it's not a SLES system, you will want to read
through the script before executing it. YMMV.
- execute the create_apt_rep.sh
You now can not only access the packages via apt, but also via YaST if you
add a installation source to the path:
- Set up your virtual host for the apache. The apt-server package
contains a template with the minimal nessecary config statement. Tailor it to your needs with:
cat vhost.apt-server.in | sed s/@LOCALDOMAIN@/your-domain.com/ | sed s#@LOCALNET@#192.168.0.0/16# >vhost.apt-server
replacing your-domain.com and 192.168.0.0/16 your domain and netmask respectively
- likewise the file /etc/apt/sources.list is only a template that you must process with
for i in sources.list.in
cat sources.list.in | sed s/@LOCALDOMAIN@/your-domain.com/ >sources.list
- The structure of directories that is create by create_apt_rep.sh allows for locally build packages to be installed via
Integrating apt repository with YaST
If your organisation is like ours, some people prefere YaST,
some apt. As both tools are based on RPM and use the same
database to retain informationa about installed packages, it
is worthwhile to synchronise the package repositories. For the
packages distributed by SuSE with the media this is allready
done above, but for locally build packages and thos
contributed by other sources, this will a take a small extra
effort. But once done you can mix and match the use of YaST
- create a directory with the following subdirectories:
and add directories for all the architecture that you
The package directory will be refered to below as
$LOCAL_PACKAGES_DIR. You can either make it
availiable via HTTP (remember the permissions, so that
your webserver can serve the pages) or you can export it
- Put your RPMs and SRPMs into the appropriate directories
- create a file $LOCAL_PACKAGES_DIR/media.1/media
containing each in an individual line:
- a descriptive label for your package collection
- a timestamp. While I do not know the exact needed timestamp,
the output of date "+%C%y%m%d%H%M%S" seems to
- a '1'. This most likely the number of the medium,
relevant when you have multiple CD media. For a online
repository 1 should allways be enough
- create a file $LOCAL_PACKAGES_DIR/media.1/products
/ Your Label here
- create a file $LOCAL_PACKAGES_DIR/content similar
to this one:
PRODUCT Your Label here
LINGUAS de en
LABEL My Local sles9 packages
LABEL.de Meine lokalen sles9 Pakete
VENDOR My Organisation
ARCH.x86_64 x86_64 i686 i586 i486 i386 noarch
ARCH.i686 i686 i586 i486 i386 noarch
ARCH.i586 i586 i486 i386 noarch
ARCH.i486 i486 i386 noarch
ARCH.i386 i386 noarch
the de Entry in the LINGUAS line is only an example
to show how the file may be localized. Also you may want to
change the DEFAULTBASE line to your prefered
- Install the autoyast-utils package. It only
contains one programm, create_package_descr, a perl
script to generate the package description files that YaST
uses to display package information in the package manager
UI. Run the script:
create_package_descr -d $LOCAL_PACKAGES_DIR -x $DISTRIB_MEDIA_DIR/sles9/CD1/suse/setup/descr/EXTRA_PROV
- now you can start the YaST package manager on add a
installation source, and give $LOCAL_PACKAGES_DIR
as the directory containing the installation source in the
Note on rebuilding the apt package from the SRPM
I have cheated a little bit when building the package. In order to
generate the documentation from the XML sources, you need xmlto.
But installing that correctly you would need a complete teTeX toolchain.
As I did not want to create SLES packages for that (yet), I have created
the needed packages xmlto and docbook-xsl-stylesheets.
docbook_4 is allready part of SLES9. Simply install xmlto
with --nodeps and everything should work just fine.
these are the varius directory hierarchies that I refer to
in this manual, so that you can keep them apart, even if I
should make a typo above:
- Directory that
contains the contents of the distribution CD images as
prepared by the create_apt_rep.sh script
- Directory tree containing the RPMs
and SRPMs vor locally build packages.