[Catalyst] what is easiest/best GNU/Linux/BSD distribution
alex.sayle at ehsbrann.com
Tue Sep 13 15:53:32 CEST 2005
On 13 Sep 2005, at 03:25BDT, David Christensen wrote:
> Alex Sayle wrote
>> We run Catalyst on Debian 3.1 with:
>> Apache 2,
>> mod_perl 2.0 (release version),
>> postgresql 8.
>> Our Debs come from deb http://pkg-catalyst.alioth.debian.org/ binary/
>> and other parts we need I roll up a deb for packages using the
>> dh-make-perl command. I keep a local Deb repository of all our own
>> packages and so far its worked very nicely.
>> We also roll our catalyst app into a deb package.
>> The result is that I can go apt-get install <inhouse-catalyst-app>
>> and all dependencies are fulfilled and away the app goes.
> That's valuable. Would you consider sharing your Debian repository
> installation procedure with others? Please? :-)
Most of our catalyst packages come from the excellent work done at
For any other packages that I need, I simply create them using
$dh-make-perl --build --cpan Catalyst::Plugin::Static::Simple
The dh-make-perl package contains the dh-make-perl script and it
should be noted that the apt-files package should also be installed as
apt-files can then detect the dependency and generate the correct
debian package dependency.
(otherwise you have to manually add the dependencies into the debian/
which will produce the following files.
Rather than manually installing the relavent .debs on to each system,
I copy them onto our repository machine.
For examples sake, I upload my packages into a incoming directory
located under the webdocument root. I host my repository though a
stock standard apache virtual host with restriction on the firewall
and on apache configs to limit access to the repository.
It looks like:
There's a couple of ways to make a apt repository, the most simplest
way it to use the dpkg-scanpackage command. cd into the binary
directory and do
binary$dpkg-scanpackages . /dev/null Packages
Which will create a simple Package index of all packages in the binary
directory. Don't forget to gzip is or apt wont pick it up. The
apt-source entry to the above index would be something like
deb http://packages.example.com/debian/ binary/
The same process can be repeated for source packages using the
This is nice and simple but becomes a bit cumbersome very quickly as
the repository has very little meta data on it so it not exactly easy
to dictate what packages you may or may not want using the
apt/preferences file. Nor does it extend very well to a large number
of packages or multiple architectures.
I tried apt-move with minor success after some hackery (its a
mirroring tool not a repository management tool). In the end I've
settled on the reprepro command. There a short howto on the web which
is very useful at,
After getting reprepro working my documentroot looks like
I hide and deny access to anything apart from pool and dists from the
web using apache directives. I then upload all my binary and sources
packages too the incoming directory and run a small shell scrip the
add packages to myrepository. under conf/ there's a file called
distributions which has:
Architectures: i386 amd64 source
Components: main non-free contrib
Description: Home grown yummy Packages for Debian Sarge
Adding a single package looks like
debian$reprepro -v --keepunreferencedfiles -b . includedeb sarge
Which will automatically make the correct directory in
and place the package where it should be.
Source packages and change files can also be added using "includedsc"
and "include" options. The repository can then be added to
deb http://packages.example.com/debian/ sarge main
deb-src http://packages.example.com/debian/ sarge main
The nice thing about this is that you have all the meta data from the
repository so you can pin packages in a much more flexible manner. For
example for some applications we've had to roll custom packages with
out own patches. But not all nodes what the patched version. Some nodes
want to stay plain vanilla Debian Sarge. These needs can be satisfied
by entries into the apt/preferences file like the following.
Explanation: Blocking all home grown packages by default
Pin: release o=Example
Explanation: Explicitily allowing our patched version
Pin: release o=Example
The result of all of this is that I can build the package once, upload
it, reindex it and roll it out in a very short amount of time.
If anyone is interested I'll follow it up with how I package up the
catalyst apps themselves.
EHS Brann System Administration Team sysadmin at ehsbrann.com
Alex Sayle alex.sayle at ehsbrann.com
More information about the Catalyst