This post will be enti­rely in English but feel free to com­ment in Polish if you want. The reason is my lazi­ness as I need to pro­vide an English trans­la­tion any­way and it’s just easier to write one ver­sion instead of two.

Troll war­ning: I am sane and have spent more than last 3 years acti­vely deve­lo­ping PLD Linux. If you want to tell me to shut up, you bet­ter find some­thing to sup­port your statements.

The problem

Or seve­ral pro­blems really:

  • The first and most obvious one is poldek still has some bugs.
  • That in turn is cau­sed by the fact that noone is wor­king on poldek any more.
  • The above is cau­sed 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 imme­diate. That is, until you realize Mis (Paweł Gajda) — despite having good inten­tions &,dash; can no lon­ger spend his time acti­vely wor­king on the pro­ject. It might not be obvious at first but check the spec in our CVS. The last snap­shot was taken four mon­ths ago and we alre­ady have 6 pat­ches on top of that. This is not bad if we are tal­king about an upstream pro­ject. But here upstream is actu­ally us.

I am afraid that one day we might be una­ble to fol­low rpm in terms of both featu­res and com­pa­ti­bi­lity. There are some people today who know C well eno­ugh to hack on the sour­ces and a small per­cen­tage of them is actu­ally capa­ble of under­stan­ding poldek’s inter­nals but one day there may be none.

But the pro­blems don’t end here. Poldek was a marvel­lous tool back when it was cre­ated. In the dark ages of early apt we alre­ady had an inte­rac­tive tool to use. But today the situ­ation is quite different:

  • Fedora/RHEL are acti­vely wor­king on yum.
  • Gen­too is acti­vely main­ta­ining emerge.
  • Debian/Ubuntu have their apt and synaptic
  • We still have the same poldek with no one to main­tain it.

And there’s more. In par­ti­cu­lar lib­pol­dek and python-poldek need to be com­ple­tely rede­si­gned to become usa­ble in some­thing even resem­bling a GUI tool. And there are some depen­dency inter­pre­ta­tion issues too. More deta­ils fur­ther below.

The solution

I can see two solu­tions here. The first and most obvious is to find a new active main­ta­iner and pro­gram­mer for poldek. Sign up today, lots of fun and joy awa­its you as you enter the aban­do­ned world. There are some things to fix, some to refac­tor and maybe a lit­tle set of desi­red new featu­res too.

The other solu­tion is to intro­duce a new pac­kage mana­ger with equal rights to those of poldek. That means keeping it up to date and making sure it always works. I’ve alre­ady taken the first step and PLD now has basic yum com­pa­ti­bi­lity. There are yum repo­si­to­ries, there is yum and yumex — a nice lit­tle GUI tool to help all desk­top users out there. This way we can avoid being cha­ined to a sin­gle tool that in future could turn into a sin­gle point of failure.

Howe­ver adding yum is not eno­ugh as there is some­thing more…

Poldek's architecture

Long time ago in the galaxy not so far away a tool was cre­ated to aid pac­kage mana­ge­ment. It was cal­led poldek and it relied and still relies on a bro­ken idea of cal­ling rpm direc­tly instead of using pro­per librpm bin­dings. This in turn for­ced poldek to reinvent a mecha­nism for depen­dency checks.

Most tools just pass the list of pac­ka­ges to librpm and the library in turn asks them what to do in spe­ci­fic cases (like unsa­tis­fied deps or file con­flicts). Poldek needed exter­nal one because there was no way to ask the rpm binary for any­thing and get usa­ble feed­back. It was either a suc­cess or a failure so every sin­gle 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 Coun­cil of One deci­ded it was worth caching the rpm’s data­base in yet ano­ther data­base but this time using a dif­fe­rent schema. That’s why poldek takes up to seve­ral minu­tes on some machi­nes every other restart (when you see a rebu­il­ding rpm data­base message).

The result? Yum’s sour­ces take as much as 2.4MB ver­sus 35MB for poldek.

Inconsistent dependency checks

There are some pro­blems adap­ting any other tool for PLD howe­ver. The reason is that for quite a long time noone bothe­red to use any other tool to manage pac­ka­ges. And PLD was fixed for poldek and poldek was fixed for PLD. And none of them han­dle the depen­den­cies like the rest of the world does.

For some reason PLD deci­ded to use the Obso­le­tes header to hold infor­ma­tion about con­flic­ting pac­ka­ges. Not that it makes any sense but that’s how poldek imple­men­ted it in the first place. You see, when you try to use the pro­per Con­flicts header and drop the Obso­le­tes header poldek displays an error mes­sage and refu­ses to install anything.

Pat­ching yum to han­dle con­flicts and unin­stall the con­flic­ting pac­kage took me about 3 minu­tes. But it tre­ats Obso­le­tes the way it was sup­po­sed to be used: to tell the mana­ger that a pac­kage is being drop­ped from the distri­bu­tion and ano­ther one pro­vi­des a repla­ce­ment. Not that two pac­ka­ges are mutu­ally exc­lu­sive (hint: mutual Con­flicts). Now image what yum does when it sees two mutu­ally obso­le­ting pac­ka­ges. Yup. It cyc­les them every time you upgrade. And now the fun part — we have more than 10 issue ver­sions (send your answers on post cards to my home address).

That’s why I pro­pose fixing out pac­ka­ging policy and poldek to han­dle deps like the rest of the world does (and maybe start using Sug­ge­sts once poldek is fixed).