On Sat 2003-08-02 at 11:01:21 -0700, [EMAIL PROTECTED] wrote:
> On Sat, Aug 02, 2003 at 07:32:20PM +0200, Benjamin Pflugmann wrote:
> > libsmbclient0-3.0-0.alpha21.3mdk -> libsmbclient0-2.2.8a-7mdk
[...]
> > Neither urpmi nor rpmdrake want to upgrade this package ("urpmi
> > libsmbclient" -> "Everything already installed"). Do you need any
> > further info?
>
> Can you add -v to the command as you were running it and then &>
> urpmc.log and send me the full log? This will produce a lot of output,
> so please send it to me off list.
>
> This is more than likely a uprm* bug or a situation of the media you had
> selected at the time you ran it.
You are right. Sorry for the false alarm. "urpmi --auto-select" wants
to do the downgrade, too. That given, do you still want/need the full
log?
> urpmc actually asks urpmq for the list of packages that would be
> updated.
I know. That was why I tried with urpmi. Just that I tried the wrong
variation of calling urpmi. ;)
[...]
> > But maybe urpmc could stop displaying the log, as soon as it
> > found the first version which it positively identifies as being lower
> > than the current one? Here that would be 1.8.0-21.
>
> Unfortunately there are a couple problems doing this.
> a) If you have a case where the newer version has a lower version number
> then it will fail. The changelog format we are using now does not
> include the epoch so I can't reliably do version comparisions from the
> changelog.
Well, my feeling is that irregular version numbers are more common
than epoch changes with lower version numbers, but I see your point.
This part could be solved by making ht ebehaviour dependend on a
match, i.e. only act this way, if a first pass finds no match at all.
> b) Right now urpmc doesn't know anything about version comparisons. It
> just looks for the data it expects.
Yeah. I thought so. That's why I did not suggest implementing a more
lax search pattern. But at the end, I am not much concerned about the
actual implementation, only that the output is not overflooded with
irrelevant log entries. So limiting the log entries as suggested
below would a good first step.
A similar case is the recent "libification" work, the split packages
show all log entries (which were copied from the old package),
although only the last one is really relevant. I didn't mention it
before, because I had no suggestion how to improve it. But maybe you
see a way.
[...]
> I've thought about adding an option to let you limit the number of
> entries shown in these situations. That is you could specify rather
> than showing the full changelog maybe only the most recent 2 entries
> would be shown.
That would be certainly an improvement.
Thank again,
Benjamin.
