Contents:

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').

more help

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.

Requisites

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 create_apt_rep.sh.
  • 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

  1. install the apt-libs and apt 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.

  2. 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 apt-server. 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.
    1. 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: http://apt.your-domain.com/apt/sles9

    2. 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:
      pushd /etc/apache2/vhost.d
      cat vhost.apt-server.in | sed s/@LOCALDOMAIN@/your-domain.com/ | sed s#@LOCALNET@#192.168.0.0/16# >vhost.apt-server
      popd
      	      
      replacing your-domain.com and 192.168.0.0/16 your domain and netmask respectively
    3. likewise the file /etc/apt/sources.list is only a template that you must process with
      pushd /etc/apt
      for i in sources.list.in 
      cat sources.list.in | sed s/@LOCALDOMAIN@/your-domain.com/ >sources.list
      popd
      	      
    4. 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 and apt.

  • create a directory with the following subdirectories:
    • media.1
    • noarch
    • setup
    • nosrc
    • src
    and add directories for all the architecture that you maintain (x86_64,i386,i586,i686,etc)

    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 via NFS.

  • Put your RPMs and SRPMs into the appropriate directories under $LOCAL_PACKAGES_DIR.
  • create a file $LOCAL_PACKAGES_DIR/media.1/media containing each in an individual line:
    1. a descriptive label for your package collection
    2. a timestamp. While I do not know the exact needed timestamp, the output of date "+%C%y%m%d%H%M%S" seems to work fine.
    3. 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 containing
    / Your Label here
    	  
  • create a file $LOCAL_PACKAGES_DIR/content similar to this one:
    PRODUCT Your Label here
    VERSION sles9-1
    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
    ARCH.noarch noarch
    DEFAULTBASE x86_64
    DATADIR .
    DESCRDIR setup/descr
    	  
    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 architecture.
  • 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 proper dialog.

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.

Directory Overwiev

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:

$DISTRIB_MEDIA_DIR
Directory that contains the contents of the distribution CD images as prepared by the create_apt_rep.sh script
$LOCAL_PACKAGES_DIR
Directory tree containing the RPMs and SRPMs vor locally build packages.

Downloads

create_apt_rep.sh
update-sles9.sh

Lutz Behnke