Bug 128607

To add: the needed package createrepo is part of SUSE LINUX 10.0, so it should be easy to generate. Is there a special reason that it is not done yet (besides manpower and time)?

The only idea I could come up with, is the fact that you might not get all security fixes if you _only_ try to get them via a yum repo of the YOU update tree (because it could theoretically contain scripts, that fix problems).

Besides that, we would need to provide YaST metadata as well - because this is the _default_ (and supported) Package Manager.

I just talked to Rudi, who will look into this...

Yes, the scripts are the problem , I know. But because of the mirror-capability of yum it is much more practical in the normal life, there are not so many important scripts, and for these the people can take yast.

Besides that, the metadata for yast must be provided, too, sure! But that's already the case for the main repositories base, GM and java: there you have yum repodata next to yast data. So I think that should be possible with updates and the different projects, too.

If you think about implementing yum support, please think about using or genrating mirror lists - that's the main feature why I really like yum.

For comparison: Fedora Core has almost no loead problems even on their main server because they have the mirror lists preconfigured in their Fedora Core - every single client will only use mirror servers in the default configuration!

I wish me this feature for a peferct suse, too :-)

To solve the load problems we have download.opensuse.org, which does some "smart" redirection stuff - but if the mirrors aren't up to date, download.opensuse.org doesn't really help ;)

Although this bug is not about mirrors I want to add something:
The best way would be, as far as I understand it, to have three servers:
* one server which is only for mirrors and onyl reachable via rsync - there are only few users which would rsync to get the cd's & dvd's, but several mirrors
* one server to provide the bittorrent links and which has mirror lists (for yum or smart or a updates yast)
* onbe server with the files itself.

In this configuration, when the main software system of suse uses mirror lists automatically, there is no more bottleneck, as far as I see.

But: this bug is still about two other things:

* mirrors lists for the existing yum repositories base, gm, java
* yum repositories (in the best case with mirror lists) for suse update and suse supplementary

Just to add: i've written a blog entry about yum and suse linux 10.0 here: [1]. It had around 5.000 klicks in one month, so I am not the only interested one.

It works with a local mirror list, the examples of the local mirror lists given at the end of the blog entry are updated when I have time to go through some ftp servers.

If there is help needed to keep such mirror lists up to date I offer my help.

[1]
http://liquidat.blogspot.com/2005/10/setting-up-yum-on-suse-linux-100.html

Dear all,

I am very interested in this mirror list. For now I am using the extra-official liquidat mirror list.

Thank you your attention,
Beco

Please keep this bug on topic, on the single request of having RPM-MD metadata (and/or yast2) for the online updates.

the update trees for 10.0/9.3 should have yum-style repos now,
untested however.

I just happened to look at this bug today and was happy to find that the update trees now contain yum repodata.  When I tried using it though, yum crashed with this error:

updates   :                                                    1/1404Traceback (most recent call last):
  File "/usr/bin/yum", line 27, in ?
    yummain.main(sys.argv[1:])
  File "/usr/share/yum-cli/yummain.py", line 92, in main
    result, resultmsgs = do()
  File "/usr/share/yum-cli/cli.py", line 480, in doCommands
    return self.updatePkgs()
  File "/usr/share/yum-cli/cli.py", line 947, in updatePkgs
    self.doRepoSetup()
  File "/usr/share/yum-cli/cli.py", line 75, in doRepoSetup
    self.doSackSetup(thisrepo=thisrepo)
  File "__init__.py", line 260, in doSackSetup
  File "repos.py", line 286, in populateSack
  File "sqlitecache.py", line 96, in getPrimary
  File "sqlitecache.py", line 89, in _getbase
  File "sqlitecache.py", line 359, in updateSqliteCache
  File "sqlitecache.py", line 251, in addPrimary
  File "sqlitecache.py", line 197, in insertHash
  File "sqlitecache.py", line 449, in values
  File "sqlitecache.py", line 441, in __getitem__
  File "mdparser.py", line 73, in __getitem__
KeyError: 'epoch'

Here is my configuration:

[updates]
name=SUSE $releasever - Updates
baseurl=ftp://ftp.suse.com/pub/suse/i386/update/10.0
enabled=1
gpgcheck=1

Thanks,
Dave

Christoph, could you help us with your in deep knowlegde about yum, if it needs "epoch" in the RPMs, as we don*t use epoch this might be the cause of this issue.

could well be the case. yum's createrepo will always add 'epoch="0"'
but this is really wrong since epoch="" and epoch="0" are really
different things.

Rudi, please add 'epoch="0"' to your scripts that generate the repodata stuff for the update trees. yum & createrepo (smart as well) are designed to work with this and fail to work with epoch="" or a missing epoch (which is even worse than epoch=""). I'v talked to mls today and looked into the rpm code where we found that rpm itself doesn't treat epoch="" == (or !=) epoch="0" in the same way in all place ;)

Looks like buildhost is also needed.  This is what I received when I tried today:

updates   :                                                    1/1411Traceback (most recent call last):
  File "/usr/bin/yum", line 27, in ?
    yummain.main(sys.argv[1:])
  File "/usr/share/yum-cli/yummain.py", line 92, in main
    result, resultmsgs = do()
  File "/usr/share/yum-cli/cli.py", line 480, in doCommands
    return self.updatePkgs()
  File "/usr/share/yum-cli/cli.py", line 947, in updatePkgs
    self.doRepoSetup()
  File "/usr/share/yum-cli/cli.py", line 75, in doRepoSetup
    self.doSackSetup(thisrepo=thisrepo)
  File "__init__.py", line 260, in doSackSetup
  File "repos.py", line 286, in populateSack
  File "sqlitecache.py", line 96, in getPrimary
  File "sqlitecache.py", line 89, in _getbase
  File "sqlitecache.py", line 359, in updateSqliteCache
  File "sqlitecache.py", line 251, in addPrimary
  File "sqlitecache.py", line 197, in insertHash
  File "sqlitecache.py", line 449, in values
  File "sqlitecache.py", line 441, in __getitem__
  File "mdparser.py", line 73, in __getitem__
KeyError: 'buildhost'

I have successfully updated a few times with yum, and everything seems to be working fine.  Is this issue resolved?

Yes, it's fixed. But let's keep this bug open until we have repodata in the supplementary trees as well (this needs some additional bits in the create_packagedescr).

the supplementary trees are basically gone and have been replaced by
opensuse buildservice repositories (that have yum data anyway).