Definite's Extractor

My findings on Life, Linux, Open Source, and so on.

Monthly Archives: July 2009

Project Denture: package manager for Fedora Long term support (LTS)

Recently, there is a thread about Fedora Extended Life Cycle (ELC) again. Old topic as it is, I am still interested in it.

The discussion mainly focuses on:

  • How are security patches being delivered?
  • ABI/API compatibility.
  • How long exactly are we going to extend?
  • Which legacy version are we going to support?
  • What resource (people who do the maintenance, disk space, etc.) does it require?

Instead to specify which release to be the LTS or ELC version,
I hereby suggest another approach, namely, project denture, it helps old releases
to chew on the new packages. 🙂

What does it do? For example, you want libwnck>=2.18 in Fedora 6, so you can switch the viewport in Beryl by clicking on the windows’ pull down menu. However, CentOS5 only offer libwnck-2.16 which doesn’t offer the viewport support.

Denture can help by DIY the libwnck rpm for you.
Firstly, it analyses the dependencies of libwnck from the current release,
at this time, F-11).
If the dependencies conflicts with black-listed packages (more on that later), it will fall back to the previous releases (at this time, F-10, F-9 and so on..) and try again, until:

  1. libwnck of newer releases (Fedora > 6) are all conflicts with black-listed packages.
  2. One of newer releases (say F-7) does not conflict with black-listed packages.

In former case, the Denture returns “Failed to upgrade” and list the conflicting black-listed packages. Otherwise the Denture builds all the middle rpms and installs them for you.

Black-listed packages

Usually, people sticks with older releases because they have some packages they don’t want to be changed. These packages, along with significant system packages, e.g. glibc, glib, python, should be black-listed and they won’t be changed.


How are security fixes being delivered?

Denture can build it for you as long as the fix does not require higher version of black-listed packages.

ABI/API compatibility

Denture should have no problem if the dependency information of
the target packages and middle packages are correct and precise.
If not, then the incorrect packages need to be black-listed.

How long exactly are we going to extend?

Denture can build it for you, as long as the newer fixes or updates do not require higher version of black-listed packages.

Which legacy version are we going to support?

Denture can build it for you, as long as

  1. Denture can build on top of it;
  2. and the black-listed packages does not get in the way to build newer packages.

What resources does it require?

Any computers with sufficient computation power and storage space to build and store rpms. Of course you can establish a repository that stores the dentured rpm for other users.

What if the packages change names (e.g. qt->qt3, qt4->qt).

Simple answer: put those in black-list.

Slightly longer answer: I accept any suggestions that solve that problem.

Denture might break the system!

Sadly, it might be true. So Denture will show big, scary warning such as:
“Denture might break your system, burn your monitor, make your harddisk scream like banshee….

When will denture be released?

No idea, maybe after I finished WritRecogn.

Will yum-complete-transaction wipe out my system?

Frankly speaking, I was also pondering this question as well.
After I read: yum-complete-transaction should be run??? Many apps to be erased…., I tried it myself.

Conclusion: yum-complete-transaction can wipe out your system, but you got a chance say no.
It just do some check an revert some transaction, but it will ask you to confirm, just like the normal yum without argument ‘-y’. Say ‘n’ to reject the transaction and it will clean up the completed transaction file.

In case it encounters “OSError: [Errno 2] No such file or directory: “, just create an empty file yum-complete-transaction asked and rerun it.