On Fri, 2011-12-02 at 21:51 +0200, Ville Skyttä wrote:
> On 12/02/2011 03:51 PM, James Antill wrote:
> > On Thu, 2011-12-01 at 22:19 +0200, Ville Skyttä wrote:
> >> ---
> >>  etc/yum.bash   |    9 ++-------
> >>  yumcommands.py |    4 ++--
> >>  2 files changed, 4 insertions(+), 9 deletions(-)
> > 
> >  I'm not sure how much normal people really want the header to disappear
> > here, do we do that for other commands?
> 
> For example the "repolist: x,y" footer

 Those are different, as they are extra data you can ignore ... but you
really need the headers to know what is going on.

>  and various grouplist headers
> disappear with -d < 2

 Uh, I'm pretty sure "yum group list -q" should be classified as a
bug ... can anyone think of a good reason for that? These are more like
section markers than headers though ... and we do output them in "list
-q"

>  and I believe there are many other examples if one
> cares to look for them; I think it's the right thing to do.

 I can't see any. The only reason it's "good" is for anything that is
trying to parse the text output ... and I'd rather not encourage that
(although it's probably doable for just getting the repoid's with
repolist ... do you handle the '*' modifier (and we could very easily
add more).

> > Also I wonder if you don't
> > really want to have some custom yum API code instead of trying to parse
> > the output of "yum repolist", Eg. we do a lot of extra work so that the
> > package numbers are good ... where I think you just want a list of
> > repoid's (and names?), which could be much faster.
> 
> I would like that, yes, but haven't got around to starting it yet.  I
> also have a feeling that the CLI code isn't too reusable everywhere so
> some refactoring or copy/pasting would be needed.

 Some of yum-utils (like repoquery) does the:

import sys
sys.path.insert(0, '/usr/share/yum-cli')

...hack, and given that we'd be shipping this with yum itself I see no
reason why we can't do that (we just have to remember to check that we
don't break it).

_______________________________________________
Yum-devel mailing list
[email protected]
http://lists.baseurl.org/mailman/listinfo/yum-devel

Reply via email to