Poldek is dead, time for Yum?

[Cezary Krzyzanowski]

Dnia 02-06-2007, So o godzinie 22:43 +0200, Jakub Bogusz napisał(a):
> 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.

No - it is a problem of using hackery tricks to achieve the goal in
poldek. Obsoletes is to be used when some program is being developed in
place of another. So You use Obsoletes to throw out something from the
distro. Making one package to provide something and obsolete it at the
same time seams insane. The behavior of yum trying to get rid of an
obsoleted package is on purpose.

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

And this is a problem? If the newer X package will need the Y in version
greater then the one current in the system, Y will get
installed/upgraded before. If You try to upgrade Y without X, it should
tell You, that You have X that needs Y to be < some version and could
suggest You, that You could fix that problem either by not upgrading X,
or by installing the newer X, which works well with the new Y.

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

True. Then again we use Obsoletes to make only one program of some gorup
stay, like smtpserver, or anything else. It's wrong. The whole idea is
bumped in the head --- hard. There are situations when I'd like to have
more then one program out of some group, like an smtpserver, or www
server, but this will make one throw away the other one! This is
Sparta-like behavior. Mostly the only thing they share is the port on
which they listen, sometimes something common like /var/mail.

PLD, as it makes ppl believe, is meant for advanced users. If I want to
install two smtpservers, that's my business. Throwing my other server is
_wrong_.

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

Exactly - nothing! Still poldek treats Suggests as Requires.


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

Pretty much yes:

[czarny w melchior yum]$ du -hcs --exclude *sqlite th-arch/
6,5M    th-arch/
6,5M    razem
[czarny w melchior yum]$ du -hcs --exclude *sqlite th-test
2,0M    th-test
2,0M    razem

> 
> It calls rpm only for install/upgrade/erase actions.

So 3 times too much, as AFAIR librpm supports all, but not totally sure here.

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

Patrys was doodling with them some time ago and the bindings aren't
fully functional replacements of poldek, ie some things are possible
only in main poldek.

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

I've seen it as both me and Patrys have tried to fix Suggests and it was
a nightmare.

> And which standards it doesn't conform?

Conflicts == error - won't install anything.
This is in particular annoying, when I do a full system upgrade and it
turns out, that some upgrading packages conflict.
Obsoletes == Conflicts.
Suggests == Requires

> No idea what what should it do without being too aggressive?
> To ask is OK only if Suggests usage stays very rare.

Config option, three possibilities:
- don't listen to suggestions (preferably display as a banner after
installation instead of custom made one like for music player backends
and plugins)
- treat suggestions as R-s (now working this way)
- ask

> 
> Nobody cared probably. Me too.

I care. I'm not nobody. The GUI for poldek topic returns as a boomerang
now and then, so ppl care. I can't find the time to hack and maintain a
GUI, but I'd greatly use one. So instead of leaving matters as they are
I suggest using something working out of the box - hence yumex. You
can't assume, that the lack of s/b writing a GUI is the same as n/b
wanting one.

Today I've noticed, that 90% programs running on my machine were
updated/tweaked/reworked and sometimes introduced to PLD by me. This
takes time and this needs to stop. I won't build a GUI from scratch just
because I'd gladly use one, as this would make me not USE the system,
but MAKE it all the time. I'm pretty much sure there are ppl like me out
there who'd use a GUI and aren't willing to reinvent the wheel and then
defend their crafted product against hundreds of attacks how the program
could be written better using library X, or method Y or in Z language.
Just take a look archive discussions bout ppl trying to make an
installer or a GUI to poldek. Most of them were just like that: "No -
don't use QT - QT sucks. Use GTK!". "No - don't use python, python
sucks, it'd be better in C".

> 
> Will be yum-missingok.patch merged upstream?

AFAIR upstream has discarded the patch, as they don't use jeffs rpm
(hence suggests). Still that's the way to go. They'll grow up till this
point eventually and till then the patch could be maintained, as it took
Patrys like 10 minut to hack.

> Or future patch fixing obsoletes flip-flop?

I don't think we should break another program to fit PLD hackery.
Instead if we can point out a use case, where only hackery like
obsoletes + provides (UUGLY!) is imminent, we could propose some
solution to jeff and maybe another property in rpm will emerge.

-----

Please - I'm not trying to troll here bout killing poldek, totally
disregarding the thing it has done for us. I feel very attached to it,
but during the years it didn't grow to support all of my needs (GUI?)
and lack of maintainers has made PLD use strange hackery in their rpms
to make some use cases possible. There is jeff, there are ppl willing to
hep solve this (me i.e.), but not with hackery. From 2 years I haven't
made a clean upgrade (once 2-3 weeks) and I'd like to live to the
moment, when I could do one without having to resolve poldeks problem,
or force things I know are good, but poldek won't listen.

Cz w rny