This post will be entirely in English but feel free to comment in Polish if you want. The reason is my laziness as I need to provide an English translation anyway and it’s just easier to write one version instead of two.
Troll warning: I am sane and have spent more than last 3 years actively developing PLD Linux. If you want to tell me to shut up, you better find something to support your statements.
The problem
Or several problems really:
- The first and most obvious one is poldek still has some bugs.
- That in turn is caused by the fact that noone is working on poldek any more.
- The above is caused by poldek’s poor source code documentation.
- That in fact is because there is only one author and maintainer.
And sure all the above may not seem immediate. That is, until you realize Mis (Paweł Gajda) — despite having good intentions &,dash; can no longer spend his time actively working on the project. It might not be obvious at first but check the spec in our CVS. The last snapshot was taken four months ago and we already have 6 patches on top of that. This is not bad if we are talking about an upstream project. But here upstream is actually us.
I am afraid that one day we might be unable to follow rpm in terms of both features and compatibility. There are some people today who know C well enough to hack on the sources and a small percentage of them is actually capable of understanding poldek’s internals but one day there may be none.
But the problems don’t end here. Poldek was a marvellous tool back when it was created. In the dark ages of early apt we already had an interactive tool to use. But today the situation is quite different:
- Fedora/RHEL are actively working on yum.
- Gentoo is actively maintaining emerge.
- Debian/Ubuntu have their apt and synaptic
- We still have the same poldek with no one to maintain it.
And there’s more. In particular libpoldek and python-poldek need to be completely redesigned to become usable in something even resembling a GUI tool. And there are some dependency interpretation issues too. More details further below.
The solution
I can see two solutions here. The first and most obvious is to find a new active maintainer and programmer for poldek. Sign up today, lots of fun and joy awaits you as you enter the abandoned world. There are some things to fix, some to refactor and maybe a little set of desired new features too.
The other solution is to introduce a new package manager with equal rights to those of poldek. That means keeping it up to date and making sure it always works. I’ve already taken the first step and PLD now has basic yum compatibility. There are yum repositories, there is yum and yumex — a nice little GUI tool to help all desktop users out there. This way we can avoid being chained to a single tool that in future could turn into a single point of failure.
However adding yum is not enough as there is something more…
Poldek’s architecture
Long time ago in the galaxy not so far away a tool was created to aid package management. It was called poldek and it relied and still relies on a broken idea of calling rpm directly instead of using proper librpm bindings. This in turn forced poldek to reinvent a mechanism for dependency checks.
Most tools just pass the list of packages to librpm and the library in turn asks them what to do in specific cases (like unsatisfied deps or file conflicts). Poldek needed external one because there was no way to ask the rpm binary for anything and get usable feedback. It was either a success or a failure so every single check in rpm had to be doubled in poldek’s code to detect all errors before asking rpm to jump in and do its job.
Then the High Council of One decided it was worth caching the rpm’s database in yet another database but this time using a different schema. That’s why poldek takes up to several minutes on some machines every other restart (when you see a rebuilding rpm database
message).
The result? Yum’s sources take as much as 2.4MB versus 35MB for poldek.
Inconsistent dependency checks
There are some problems adapting any other tool for PLD however. The reason is that for quite a long time noone bothered to use any other tool to manage packages. And PLD was fixed for poldek and poldek was fixed for PLD. And none of them handle the dependencies like the rest of the world does.
For some reason PLD decided to use the Obsoletes header to hold information about conflicting packages. Not that it makes any sense but that’s how poldek implemented it in the first place. You see, when you try to use the proper Conflicts header and drop the Obsoletes header poldek displays an error message and refuses to install anything.
Patching yum to handle conflicts and uninstall the conflicting package took me about 3 minutes. But it treats Obsoletes the way it was supposed to be used: to tell the manager that a package is being dropped from the distribution and another one provides a replacement. Not that two packages are mutually exclusive (hint: mutual Conflicts). Now image what yum does when it sees two mutually obsoleting packages. Yup. It cycles them every time you upgrade. And now the fun part — we have more than 10 issue
versions (send your answers on post cards to my home address).
That’s why I propose fixing out packaging policy and poldek to handle deps like the rest of the world does (and maybe start using Suggests once poldek is fixed).
Ostatnie komentarze