Poldek is dead, time for Yum?

[Jakub Bogusz]

On Sun, Jun 03, 2007 at 06:35:27PM +0200, Cezary Krzyzanowski wrote:
> 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.

Not poldek. Beginning in rpm alone. And not hackery, just using feature
provided by rpm.

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

yum just doesn't support package replacements. AFAIR RH never provided
replacements within distro and I think FC follows the same way.
So they don't care about existence of replacements and double meaning
of "Obsoletes".

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

Does yum suggest Y upgrade in such case?
poldek performs upgrade (not sure if greedy mode isn't required for it).

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

Rarely needed for SMTP. If it were needed, it would be done, like it has
been done in case of HTTP.

Another examples of replacements:
- cron daemons processing the same crontab
- libGL coming from Mesa, NVidia and ATI

> > And what "Suggests" have to do with package replacements?
> 
> Exactly - nothing! Still poldek treats Suggests as Requires.

OK, I was misleaded by mentioning both things together.
Needs an update for RPMSENSE_MISSINGOK flag interpreting.

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

Probably. But writing "no libpoldek" is not true.

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

I don't see a nightmare there. Just nicely formatted pure C code.

Yes, it uses internal APIs extensively in logic code, so it could be hard
to understand _at the first sight_. But not messy.

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

And what should it do beside printing which package(s) cause problem?
Sorry, there is no AI module.
Reporting conflict is correct behaviour.

> Obsoletes == Conflicts.

?

> Suggests == Requires

The same as in all older tools or tools using current rpm.org.
Needs adjustment, but we can expect it to _be_ merged upstream.

BTW, I asked about _code_ (not logic) not being standard-compliant.

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

Let it be.

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

Supposed answer is the same as for Suggests case: they don't support
replacements.

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

Splitting obsolescences and replacements to different tags would be some
solution.


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