Poldek is dead, time for Yum?

[Cezary Krzyzanowski]

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

Well, however we'd agree to classify that behavior, You have to admit,
that the construct is bizarre in it's form. EOT - commenting SPEC code
wasn't my intention to begin with.

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

But we do and we care, so it's up to us to find a solution for this and
obviously FC won't help, because of their behavior stated above. Hackery
is good for short term solutions, but this either needs a rethink of our
semantic of SPEC macros, or propose some new one for situations we
encounter daily.

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

I don't know. S.E.S.J.A. is imminent (System Eliminacji Studentów Jest
Aktywny) and I don't have the time to investigate. Mostly the strange
obsoletes flip/flopping stopped me from further digging into this
matter, hence the first mail here.

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

Don't they clearly belong to Conflicting classes? I get a Conflict and
if I know what I am doing I could just force the install.

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

Clearly.

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

I'm young, I'm eager to overstate things, flatten them to black-white
situations. Sry.

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

Well - it looks good, but writing propriety rpm db system and loading it
(whole) to memory from the rpm db on fs is such a gooooood idea.

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

No argue here - not for poldek itself at least. I mean, that throughout
the years I've gathered bundles of programs I use and they stay more or
less the same time. Still on every upgrade I get some Conflicts from
poldek, which stop me from clean upgrade, although the programs I use
don't change and they're installed properly.

No, don't have any hard example. I'll try to provide some if this
discussion, or rather solutions implementing will be under way during my
next upgrade (which isn't to be as long as S.E.S.J.A).


> 
> > Obsoletes == Conflicts.
> 
> ?

That we use Obsoletes to force only one service provider, like the given
smtpservice.


> Let it be.

Ok - if the matter isn't solved till exams end, I'll look into this.

> 
> [...]
> > > Will be yum-missingok.patch merged upstream?
> > 
[...]
> > 
> > > Or future patch fixing obsoletes flip-flop?
> > 
> 
> Supposed answer is the same as for Suggests case: they don't support
> replacements.

Yea. But still we need it and as Patrys volunteered to keep the suspend
alive till upstream commit, we need to think bout starting using the new
given macro.

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

Well - I'm no one to argue with You. Let's face it --- there are only a
bunch of ppl long enough here to give new semantics (our semantics) for
rpm macros. I'm not one of them. Clearly You are, as You are able to
throw a real example of some behavior or some solution provided for some
other behavior. Maybe glen. I'm totally not up to it, as I'd fuck things
more then help here - I just haven't seen my share of use cases to judge
what would be useful and what not.

So, to keep the discussion focused, some thins to solve:
- Conflicts vs Provides + Obsoletes
The thing with Conflicts is when we thing something Conflicts? Like
let's say init and initng? They provide exacly the same functionally and
*usually* don't get installed together. Then again I've got my laptop
with both and the work.

Evince and evince-gtk --- clearly the have the same files and
directories, but I just could move all the files to evince-gtk and make
them coexist, but the question is, does this make sense. Isn't that a
perfect place for Conflicts?

Should various daemons Conflict? Or remove other daemons? Like the smtp
groups, http group?

- How should Obsoletes work
Should it be used to throw things out of the distro (which will be
useful for us, as we make a release once a few years and often change
stuff in one release, not to mention Always Current Distro mode), or be
more like replace (installing Postfix? Get rid of qmail).
- Split Obsoletes to Obsoletes and Replaces ?

Cz w rny