Poldek is dead, time for Yum?

[Jakub Bogusz]

On Thu, May 31, 2007 at 06:57:45PM +0200, Cezary Krzyzanowski wrote:
> Dnia 30-05-2007, Śr o godzinie 23:19 +0200, Jakub Bogusz napisał(a):
> > > 
> > For replacement one can use such construct:
> > Provides: smtpserver
> > Obsoletes: smtpserver
> > to replace any other package which provides smtpserver.
> > And it won't work with Conflicts instead of Obsoletes - self-conflict
> > is always an error.
> > 
> 
> 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).

> We need to decide which rpm use, which to follow. Resolve this problem
> with conflicts and with suggests once and for all.

"Conflicts" means "don't install these packages together", not "remove
the other one".
Use Obsoletes to get the latter action.

And what "Suggests" have to do with package replacements?

> > As for poldek:
> > - poldek's indexes are smaller than yum's
> 
> [root w melchior .poldek-cache]# du -hac
> ftp_ep09.pld-linux.org.dists.th.PLD.x86.64.RPMS/
> 4,0K    ftp_ep09.pld-linux.org.dists.th.PLD.x86.64.RPMS/packages.ndir.md
> 6,6M    ftp_ep09.pld-linux.org.dists.th.PLD.x86.64.RPMS/packages.ndir.gz
> 4,0K
> ftp_ep09.pld-linux.org.dists.th.PLD.x86.64.RPMS/packages.ndir.gz.md5
> 740K
> ftp_ep09.pld-linux.org.dists.th.PLD.x86.64.RPMS/packages.ndir.dscr.gz
> 4,0K
> ftp_ep09.pld-linux.org.dists.th.PLD.x86.64.RPMS/packages.ndir.dscr.gz.md5
> 440K
> ftp_ep09.pld-linux.org.dists.th.PLD.x86.64.RPMS/packages.ndir.dscr.i18n.gz
> 4,0K
> ftp_ep09.pld-linux.org.dists.th.PLD.x86.64.RPMS/packages.ndir.dscr.i18n.gz.md5
> 4,7M
> ftp_ep09.pld-linux.org.dists.th.PLD.x86.64.RPMS/dirindex-of-pndir.tndb
> 4,0K
> ftp_ep09.pld-linux.org.dists.th.PLD.x86.64.RPMS/dirindex-of-pndir.tndb.md5
> 13M     ftp_ep09.pld-linux.org.dists.th.PLD.x86.64.RPMS/
> 13M     razem

$ du -shc /home/services/ftp/pld/dists/th/PLD/i686/RPMS/packages*ndir*
[...]
8,1M    total

dirindex is locally generated.

> [root w melchior .poldek-cache]# du -hac --exclude
> *sqlite /var/cache/yum/th0       /var/cache/yum/th/headers
> 4,0K    /var/cache/yum/th/packages/vserver-packages-1-7.noarch.rpm
> 4,0K    /var/cache/yum/th/packages
> 4,0K    /var/cache/yum/th/repomd.xml
> 0       /var/cache/yum/th/cachecookie
> 752K    /var/cache/yum/th/primary.xml.gz
> 1,7M    /var/cache/yum/th/filelists.xml.gz
> 528K    /var/cache/yum/th/other.xml.gz
> 3,0M    /var/cache/yum/th
> 3,0M    razem

Are you sure this is th, not th-test?

$ du -shc /home/services/ftp/pld/dists/th/PLD/i686/RPMS/repodata/*
4,4M    /home/services/ftp/pld/dists/th/PLD/i686/RPMS/repodata/filelists.xml.gz
3,1M    /home/services/ftp/pld/dists/th/PLD/i686/RPMS/repodata/other.xml.gz
2,4M    /home/services/ftp/pld/dists/th/PLD/i686/RPMS/repodata/primary.xml.gz
4,0K    /home/services/ftp/pld/dists/th/PLD/i686/RPMS/repodata/repomd.xml
9,8M    total

$ du -shc /home/services/ftp/pld/dists/th/test/i686/RPMS/repodata/*
1,8M    /home/services/ftp/pld/dists/th/test/i686/RPMS/repodata/filelists.xml.gz
192K    /home/services/ftp/pld/dists/th/test/i686/RPMS/repodata/other.xml.gz
304K    /home/services/ftp/pld/dists/th/test/i686/RPMS/repodata/primary.xml.gz
4,0K    /home/services/ftp/pld/dists/th/test/i686/RPMS/repodata/repomd.xml
2,3M    total

> The excluded sqlite files are databases made *localy* from d/l-ed xml-s.
> 
> > - poldek supports differential index updates
> 
> I don't know bout that in yum. Still - if it isn't there, implementing
> it shouldn't be a big fuss.
> 
> > - yum's indexes contain only C descriptions, no translations
> 
> I'm not sure is it a yum feature (or rather the lack of it), but I think
> createrepo makes the indexes so. Maybe it could be fixed.

Well, I think I know how it works in RH/FC.
IIRC translations for all packages were kept in huge single package
(specspo).

> > - poldek has nice interactive mode, but no comparison here (I didn't
> see
> >   yum's)
> yum shell
> 
> > And I'm not arguing against supporting yum; just against replacing
> > poldek with 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*.

> no real bindings outside exist, no libpoldek.

And what does poldek-libs package contain?
Or python directory in sources?

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

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?

> 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.

> And no X GUI came to life ever throughout the years.

Nobody cared probably. Me too.

> 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?


-- 
Jakub Bogusz    http://qboosh.pl/