[Yum-devel] repoquery/yumquery/something

[Panu Matilainen]

On Fri, 10 Sep 2004, seth vidal wrote:

> On Fri, 2004-09-10 at 08:10 +0300, Panu Matilainen wrote:
> > On Thu, 9 Sep 2004, seth vidal wrote:
> > 
> > > Hi everyone,
> > 
> > Hello! (bet you didn't expect to see me here :)
> 
> I always figured you'd come around. ;)

Hehe.. well it'll  certainly a breather of fresh air to hack something 
rpm/depsolver related in python for a change :)

> 
> > Lets see how it goes. You can always split it out of the yum package if 
> > that comes an issue, eg the repomd python libraries + utils that use them 
> > into separate package or something.
> 
> Well the repomd libraries have always been intended as a separate lib -
> but I really didn't feel like packing 3 python modules in separate pkgs
> for a yum install. :) People get annoyed when they need a depsolver to
> install a depsolver.

Nod. Not an issue if the repomd libraries come with a default FC/whatever
installation but for people downloading separately it is. And yum isn't 
exactly big package...

> 
> > Cli override good. What I'd actually like to see is the repository configs
> > be split out of yum.conf and into /etc/repodata.conf or such and
> > everything that uses the new repodata model using that instead of
> > /etc/yum.conf, /etc/sysconfig/rhn/sources etc.
> 
> Two thoughts on that:
> if it's gonna happen go whole-hog and dump the .conf file entirely -
> repo configs should be solely xml stored in a dir somewhere.
> 
> You'll note - yum/repos.py has a note about being able to pack repo
> config info in from xml files.

Then we'll need a tool for adding and removing repositories into the .xml
file - I don't consider xml "end user editable" by any means.  Something
like 'repoconfig --add http://foo.bar.com/some/repo' perhaps. But agreed - 
we don't want to end up parsing yum.conf, up2date's sources, apt's 
sources.list[.d/*] and all from every tool that's supposed to read the 
config, better have it in one place and instead of yet another 
config-file-format use xml for it.

> 
> > Another related thing: standardizing on the metadata download place, eg 
> > /var/cache/repodata and again everything using that instead of 
> > /var/state/apt/.. etc.
> 
> No objection.
> 
> > Sounds nice. Having slept over this idea I've come to the conclusion I 
> > don't give a rats a** whether it's rpmquery compatible or not - in fact it 
> > might be better just to start off clean without any silly compatibility 
> > burdens. Besides, rpm's default query output format predates multilib 
> > (and various other things) leading to silliness like:
> > [pmatilai at linox01 pmatilai]$ rpm -q glibc
> > glibc-2.3.2-95.20
> > glibc-2.3.2-95.20
> > 
> > ..when it actually should list the arch in there as well without resorting 
> > to --qf tricks, which the average joe user certainly doesn't know about 
> > and wonders why he has two glibc's installed.
> > 
> 
> My general world view is that maybe we should dump the old standby for
> pkg naevr display and go to something more realistic.

Certainly...

> 
> pkg with a zero epoch:
> name-ver-rel.arch
> pkg with a non-zero epoch:
> epoch:name-ver-rel.arch

...but I think it should be easy to parse from scripts, and conditionals 
like that make life more complicated. I wouldn't mind showing epoch 
always, zero (or absent) or not since absent epoch means zero anyway these 
days. Arch certainly should be present at all times in the output.

	- Panu -