Package management

[placey]

I'm using a WBL3 VPS here on Rimu, and I have some questions about packages. I would like to use apt to manage everything, but at the same time I need to install a package of a later release than that in the apt repository. In particular, I want Postfix 2.1.x, but the latest apt accessible version is 2.0.16. So...

Can I add lines to the /etc/sources.list to include another apt repository, or will this just confuse things?

Currently, /etc/sources points to Rimu, where does Rimu get its package feed from? How often are packages upgraded? I think Postfix 2.1 came out in May.

What's the recommended mechanism for installing a package later than what's known to apt?

Thanks in advance,
Pete

[retep]

Hi Pete. RimuHosting have our own apt repository for the WBEL3 RPMs. We grab these from the official WBEL3 repositories.

The apt repository is a self-consistent set of RPM packages. They are all built against each other. And they all use compatible library interfaces.

When you opt to go with a custom version of an RPM, apt will no longer keep that RPM up to date for you. You will manually need to install updated RPMs.

Any RPM for a new version of a package should be built for your particular distro. If you cannot find a WBEL3 (or RHEL3) RPM, you may want to try a FC1, FC2, or RH9 RPM (probably in about that order). If you get errors about dependancies I recommend you do _not_ force the install.

You may be able to find an apt repository for WBEL3 with the new RPM. But that is not so likely. Typically 3rd party apt repositories provide RPMs that don't exist at all in the original repository (to avoid conflicts).

If you fail to find the binary RPM for the package version you need and your distro version, then you should build from the src rpm.

Some packages have interdependancies. And in that case you may need to build a set of RPMs. e.g. upgrading to the latest MySQL 4.1 means you'll need a new php_mysql rpm.

If there is no src rpm available, then I suggest you apt-get remove the package. Then make and install it from the tar.gz source. A wee heads up: The config files locations in this instance may not match up with the default rpms install locations.

In general I would recommend against installing newer versions of RPMs unless a) you really need the extra functionality and b) know what you are doing.

If you have a) but not b) then please pop in a support ticket. We may be able to do the custom install for you. For quick installs we will often not charge for the work.

[placey]

Peter,

This is fine. I have no problems installing an RPM manually or building from source.

You said off list "typically new features/new versions are not put into existing distros." Does this mean that outside of bugs and security fixes, we're frozen in time when we install a particular distro? How then does anyone move forward without slowly aging out the usefulness of apt, yum, etc.? Do you have to wait for the entire distro to go to the next release and update all your packages at once? Does Debian (unstable) work this way too? When I look at Debian repositories I see that they are very up to date.

Pete

[retep]

Hi.

There are two main ways distros use to 'keep current'.

1) Some distros puts out a new release every now and then (e.g. Fedora Core puts one out every 6 months or so, e.g. FC1->FC2, and FC3 planned for November). These distros intend these releases to be quite stable for the period of the next release cycle (though if you run a FC2 box it probably won't seem that way with apt-get upgrade always installing new packages).

WBEL is receiving 'respins' where batches of updates are pushed out. There was a pretty big one in July. So it is kind of a 3.1 right now.

I believe that there is a RHEL4 in the works. When that is released I suspect that there will be a apt-get upgrade path for current WBEL3 users.

2) Some distros, like Debian, have repositories that let the user choose their stability vs. newness tradeoffs. With their 'testing' repository always having the latest packages. Using the debian 'testing' repository keeps you current with the very latest RPMs. It also means that you'll be getting new package updates all the time. And have things changing quite a bit. Not to mention the occasional bug/problem. This is ideal for some people (e.g. geeks/tinkeres), but not for others (people trying to provide a stable service).

Upgrading your distro 'version'
Tools that manage dependancies, like apt, can theoretically mix and match RPMs/packages from different repositories. In practise, if you choose to install a package from a newer repository you may find yourself needing to upgrade everything else. e.g. a new rpm that you want may need a new version of ssl, which may need a new glibc, which means pretty much every other package needs to be updated.

The apt-get distro upgrade process is relatively simple. It goes like this:
updated the /etc/apt/sources.list; apt-get update; apt-get dist-upgrade. This will replace most (if not all) of your RPMs/packages and probably install a bunch of new ones. And its the kind of process where you would want to do a good backup before embarking on the upgrade (we can do a file system snapshot for you when the time comes).

There is also an option where we can install a new/clean distro for you and mount your old file system somewhere (e.g. /backups) where you can copy off your data and settings to the new VPS. This is pretty much doing a reinstall/re-setup.

Minimizing 'Upgrade Pain'
My advice is:
- whereever possible, use the packages you have in your default/preferred distro.
- if you must have a new feature in a particular package, try to install that particular package/app.
- when a new distro comes out, postpone any move to it until you feel you really need to (e.g. you need some new feature in the distro). Your current distro will likely be kept up to date with bug and security fixes. And by postponing a distro upgrade you can same a lot of time and effort. You may even be able to skip a whole upgrade cycle.