Poldek is dead, time for Yum?

[Patryk Zawadzki]

On 6/2/07, Jakub Bogusz <qboosh w pld-linux.org> wrote:
> On Thu, May 31, 2007 at 06:57:45PM +0200, Cezary Krzyzanowski wrote:
> > Ok, but this will make yum/yumex juggle with thing providing the
> > smtpserver. Imagine You have two of them Mail and Post. You run yumex,
> > and it will deinstall Mail and install Post. On another run it will do
> > the opposite - this isn't a solution either.
> So it's problem with yum and yumex.
>
> In PLD there are several hunderds of Conflicts which are _NOT_ to be
> solved by removing conflicting package.
>
> Most of them are in form "Y < v" which mean, that package Y need to be
> upgraded before installing/upgrading package X (and user most likely
> DOESN'T want package Y to be removed).

No, I changed yumex to propose uninstallation for unversioned
Conflicts where upgrading does not fix the deps. And that patch is not
yet in PLD as I want to have a clear way to perform depsolving so we
have consistent behaviour in both poldek and yum.

> > I'm not very happy bout the perspective of replacing it, but in the all
> > years it has become a real mess. It uses rpm directly, not via librpm,
> It calls rpm only for install/upgrade/erase actions. Packages and database
> are queried through librpm*.

To be more accurate, it uses librpm to rebuild its own index of rpmdb.

> > no real bindings outside exist, no libpoldek.
> And what does poldek-libs package contain?
> Or python directory in sources?

Both are unusable for any external app. libpo{l,cli}dek lack some
depsolving functionality (code is in poldek binary) and python
bindings are non-pythonish and provide no way of listing repos (yet
still require you to pass a repo name). Reported that twice, last time
I think was 3-4 months ago. No reply.

> > The code is messy and not
> > standard-compliant.

That is simply not true.

> Huh? Have you ever looked at poldek code?
> There are some things that one may say about it (e.g. too big because of
> compliance with many rpm versions), but messy?
> And which standards it doesn't conform?

The only problem I have with the sources is the lack of documentation.
Comments are sparse and some functions seem to be randomly placed
around the files.

> > And there is nobody to develop it - like making it
> > understand Suggests.
> No idea what what should it do without being too aggressive?
> To ask is OK only if Suggests usage stays very rare.

I think it should ignore it and display it as a banner (current
functionality implemented via %banner). Then I could easily implement
a tool that shows you possible extensions to your system even months
after upgrade (like "how to make totem play file X? I'll just check
what packages are suggested").

> > And no X GUI came to life ever throughout the years.
> Nobody cared probably. Me too.

True. I cared but mis didn't ;]

> > By using Yum we get a maintained product, a GUI. With it using python
> > and dbus we can easily extend it's functionality to the needs we have.
> > It won't become a small program surrounded with thousands of quick hack
> > patches submitted, because something didn't work.
> Will be yum-missingok.patch merged upstream?
> Or future patch fixing obsoletes flip-flop?

Obsoletes can be simply disabled and I am willing to support the
missingok patches until current rpm hits fedora (or hell freezes,
whichever comes first but I have witnessed jeff talking to fedora devs
disussing placing rpm as rpm5 in fedora-extras).

-- 
Patryk Zawadzki
Generated Content