Hello there,

I tried 'dnf install xemacs-packages-extra' in dnf-0.2.20 on F18 and my development version and both install xemacs-pacakges-extra and the dependencies.

What dnf version are you using? Do you have the fedora repository enabled? The reason why the output doesn't match the package name is that dnf doesn't see the 'xemacs-package-extra' package, and guesses that what you meant was installing 'xemacs' at version 'packages-extra'.

(possibly a dup of bug 903687)

(libsolv's selection functions are pretty good in translating strings to package lists. You may want to take a look at how they are implemented.)

(In reply to comment #3)
> (libsolv's selection functions are pretty good in translating strings to
> package lists. You may want to take a look at how they are implemented.)

I think the selection functions is what got extracted from the selection mechanisms in solv.c at some point? I was looking at those before implementing the current "Subject" parsing and used the principles from there. There is one thing I meant to ask you: is there an easy way to detect whether a given string represents the version part for some package (similarly to looking for provides via FOR_PROVIDES). Also, how do you recommend dealing with case-insensitive package name lookups? (I'm using case-insensitive dataiterator now)

Yes, they are a generalization from the solv.c code.

Regarding the version part: There's no easy way. Simply checking if the id for the string exists is not enough, as the canon NVR form doesn't include the epoch, so you need to do epoch autopromotion.
I'm not sure why you need this test, I don't seem to need it in the selection code. Can you give me an example where it is needed?

Regarding case insensitive: The selection code simply iterates over all packages and matches the ->name entry. A dataiterator also works, of course, but there's more overhead involved.

Also, there are two ways to implement case insensitive matching: You can do all matches case insensitive right away, or you can do the insensitive matching only after a case sensitive match failed. The latter strategy is what I currently do in solv, it has the advantage that it still works if there are packages with the same name and different case in some repos.

#rpm -q dnf
dnf-0.2.20-1.gitdec970f.fc18.noarch

I installed a bunch of packages from updates-testing repo but that repo is now disabled FYI.  If you any further info, let me know

(In reply to comment #5)
> Yes, they are a generalization from the solv.c code.
> 
> Regarding the version part: There's no easy way. Simply checking if the id
> for the string exists is not enough, as the canon NVR form doesn't include
> the epoch, so you need to do epoch autopromotion.
> I'm not sure why you need this test, I don't seem to need it in the
> selection code. Can you give me an example where it is needed?

It's not strictly needed, it's just to detect an input error straight away:

If the user wants to install a package called "a-bc" but makes a mistake and types "install a-bd", where "a" is an existing package and we can't check that "bd" doesn't exist as a version, we try to install "a" at the nonexistent version "bd". That results in the "nothing provides requested a = bd" error, instead of just saying early "no package matching a-bd" or something similar. But of course both cases end up in an error, it's just the one with the equal sign in it looks weirder.

> Also, there are two ways to implement case insensitive matching: You can do
> all matches case insensitive right away, or you can do the insensitive
> matching only after a case sensitive match failed. The latter strategy is
> what I currently do in solv, it has the advantage that it still works if
> there are packages with the same name and different case in some repos.

That is a good idea, especially considering that looking through FOR_PROVIDES first will speed this up dramatically for majority of cases.

Maybe you should error out right away if no package matches the specification instead of creating a solver job.
(You can still pass on requests like 'dnf install foo=3', because it's clear what the user meant in that case. Dunno if dnf/yum supports such jobs, though.)

(In reply to comment #8)
> Maybe you should error out right away if no package matches the
> specification instead of creating a solver job.

I could but then the physical lookup of packages happens twice in case the package actually exists --- once when preparing the job, second time when libsolv is doing the resolving:) (though I realize that this is very negligible speed-wise)

(In reply to comment #9)
> (In reply to comment #8)
> > Maybe you should error out right away if no package matches the
> > specification instead of creating a solver job.
> 
> I could but then the physical lookup of packages happens twice in case the
> package actually exists --- once when preparing the job, second time when
> libsolv is doing the resolving:) (though I realize that this is very
> negligible speed-wise)

hm, that doesn't make much sense. that's because I still haven't made up my mind what to do here. I like the way the argument parsing is done now, that is doing the best guess and trying to see if names and arches are existing. it just would be nice for completeness to be able to do the same for version. But as you're pointing out it's not necessary (and would probably cost us some memory with another version of FOR_PROVIDES)

In any case, this is a dup of bug 903687 and should work in hawkey-0.3.8. Rahul, if it does not work for you then, feel free to reopen this one.

*** This bug has been marked as a duplicate of bug 903687 ***