[Yum-devel] Yum CLI/API consistency

[Paul Nasrat]

On Thu, 2006-01-26 at 18:08 -0500, seth vidal wrote:
> On Mon, 2006-01-23 at 12:14 -0500, Paul Nasrat wrote:
> > Seth, 
> > 
> > You asked for some feedback about this sort of stuff so here's one case
> > I think I should mention.
> > 
> > Currently we have a bunch of logic in cli.py which really should be
> > handled by the YumBase.install() YumBase.update() and YumBase.remove()
> > functions.
> > 
> > End goal - as a user I want to install everything[0]:
> > 
> > cli: yum install *
> > API: yum.install('*')
> 
> gotcha. No implicit objection. There's a tiny bit of 'but it should be
> prettier' but oh well.


> > Currently cli uses packages.parsePackages, where YumBase.install uses
> > searchNEVRA. The attached proof of concept patch makes install('*') work

> and the matching isn't quite the same b/t parsePackages and sqlite glob
> - b/c the globbing matches w/i a column, not b/t columns.

> So parsePackages will return something different than sqlite globbing
> for things like:
> 
> foo-*-1.*

Yes, in packages.parsePackages we do def buildPkgRefDict(pkgs).  If we
considered that to be part of the packageSack implementation, then a
sqlite implementation could do something like (forgive my sql, there is
probably a better way):

CREATE TEMP TABLE lookup ( na TEXT, pkgId INTEGER) 
INSERT into lookup SELECT name || '.' || arch, pkgId from packages;

For each of the formats we build into that dict anyway.  Then we just
match the glob on that index or run regex on it in the non sqlite sack
case.

> where the stars are intended to match PART of the name AND part of the
> version AND the arch.

Thus we can match in the same way :)

> > I think we should be moving logic from cli.py to the methods in the
> > YumBase object.  So that for non cli/pwd interactive things we pass off
> > to YumBase.install().  Does this sound reasonable - I'll try and get a
> > more complete patch done and clean up cli.py.
> 
> I agree but we also need to:
> 1. make it so the expected behavior doesn't change too much

Indeed. I think that is acheivable - we make searchNEVRA work as you
might expect (it breaks out into a WHERE query as is) then create an
index, view, temp table to look up if we call parsePackages.

Paul