What happens with this model? You will have to use the same version for most applications during that time. For instance, the official version of PHP that will be supported by Ubuntu Server 12.04 LTS in that term will be 5.3.10. That is to say, during this period of support, Canonical only will provide security updates and bug fixes for that package. Sometimes, some versions are updated or new features are introduced to the release, but it is not the normal behaviour.
In these cases, you will have to maintain the package versions that are not supported by the official distribution. In this article, I am going to talk about the particular situation of Ubuntu or Debian. For my tests, I will use an Ubuntu Server 12.04 virtual machine and the application chosen as an example will be the text editor nano.
So the idea of manually maintaining a package is to grab its source code, drop it off in the machine where we want to compile it (for example a 32-bit server), install the dependencies for that application, modify its configure file and finally, build the deb package. Afterwards, you will be able to distribute the package to the rest of servers by using tools such as Puppet.
First of all, let's get started by installing the needed applications to automatically make packages. Then, the source code of nano will be downloaded and unpacked.
root@ubuntu-server:~# aptitude install build-essential dh-make devscripts autoconf autotools-dev lintian
root@ubuntu-server:~# mkdir /tmp/nano ; cd /tmp/nano
root@ubuntu-server:/tmp/nano# wget http://www.nano-editor.org/dist/v2.2/nano-2.2.6.tar.gz
root@ubuntu-server:/tmp/nano# tar xvzf nano-2.2.6.tar.gz ; cd nano-2.2.6
Then, you have to install the dependencies required to compile the application: the developer's libraries for ncurses and the texinfo package (documentation system for on-line information and printed output).
root@ubuntu-server:/tmp/nano/nano-2.2.6# aptitude install libncurses-dev texinfo
At this time, you are ready to prepare Debian packaging from an original source archive, all this by means of dh_make, a tool which allows to convert a regular source code package into one formatted, according to the requirements of the Debian policy. It must be invoked inside a directory containing the source code, which has to be named <packagename>-<version>, where <packagename> must be all lowercase, digits and dashes.
root@ubuntu-server:/tmp/nano/nano-2.2.6# dh_make -e root@ubuntu-server.local -f ../nano-2.2.6.tar.gz
Type of package: single binary, indep binary, multiple binary, library, kernel module, kernel patch?
[s/i/m/l/k/n] s
Maintainer name : root
Email-Address : root@ubuntu-server.local
Date : Sat, 12 May 2012 18:56:39 +0200
Package Name : nano
Version : 2.2.6
License : blank
Type of Package : Single
Hit <enter> to confirm:
Done. Please edit the files in the debian/ subdirectory now. nano
uses a configure script, so you probably don't have to edit the Makefiles.
After that, dh_make proceeds to generate a Debian subdirectory and the necessary control files in the program source directory. Those control files are customized with the package name and version extracted from the directory name. In addition, a new tgz file with the original program source code and packed with the Debian standards is created.
root@ubuntu-server:/tmp/nano/nano-2.2.6# ls -lh ../nano_2.2.6.orig.tar.gz
-rw-r--r-- 1 root root 1.5M Nov 22 2010 ../nano_2.2.6.orig.tar.gz
root@ubuntu-server:/tmp/nano/nano-2.2.6# tree debian
debian
├── changelog
├── compat
├── control
├── copyright
├── docs
├── emacsen-install.ex
├── emacsen-remove.ex
├── emacsen-startup.ex
├── info
├── init.d.ex
├── manpage.1.ex
├── manpage.sgml.ex
├── manpage.xml.ex
├── menu.ex
├── nano.cron.d.ex
├── nano.default.ex
├── nano.doc-base.EX
├── postinst.ex
├── postrm.ex
├── preinst.ex
├── prerm.ex
├── README.Debian
├── README.source
├── rules
├── source
│ └── format
└── watch.ex
1 directory, 26 files
No comments:
Post a Comment