12:13 a.m.
I've been working on a new version of createrepo that uses the yum
modules to read in the package metadata. It's not really changing
createrepo fundamentally it just simplifies the code and reduces a lot
of duplication b/t createrepo and yum. However, one of the things that
comes out of this is the ability to create 'fake' yum package objects
comprised of data sucked directly out of koji.
The idea is that instead of getting a list of pkgs, getting the metadata
from them, then putting that metadata into the repodata xml format you
could just connect to koji with a list of specific packages you wanted,
request where the packages exist on disk (or a url to retrieve them) and
all the package metadata directly.
anyway -for simplicity purposes it would be most convenient to do this
by forming an xml-rpc connection to koji and asking it for all the
required metadata for any particular package.
Right now the simplest way would be to have the xml-rpc connecting
module create a yum packgeobject and just submit it to the existing
class.
So, what I'm wondering is:
1. is all of this info available from inside koji?
2. is it possible to connect to the xml-rpc interface anonymously?
3. will it actually be faster or at least better to do this at all?
-sv
2:48 a.m.
On 12/17/2007 07:13 AM, seth vidal wrote:
I've been working on a new version of createrepo that uses the
yum
modules to read in the package metadata. It's not really changing
createrepo fundamentally it just simplifies the code and reduces a lot
of duplication b/t createrepo and yum. However, one of the things that
comes out of this is the ability to create 'fake' yum package objects
comprised of data sucked directly out of koji.
The idea is that instead of getting a list of pkgs, getting the metadata
from them, then putting that metadata into the repodata xml format you
could just connect to koji with a list of specific packages you wanted,
request where the packages exist on disk (or a url to retrieve them) and
all the package metadata directly.
anyway -for simplicity purposes it would be most convenient to do this
by forming an xml-rpc connection to koji and asking it for all the
required metadata for any particular package.
Right now the simplest way would be to have the xml-rpc connecting
module create a yum packgeobject and just submit it to the existing
class.
So, what I'm wondering is:
1. is all of this info available from inside koji?
2. is it possible to connect to the xml-rpc interface anonymously?
3. will it actually be faster or at least better to do this at all?
Well. What info do you need? You might have a look into koji list-api!
Basic info:
[oliver@tuborg ~]$ koji rpminfo openssl-0.9.8b-17.fc8.alpha
RPM: openssl-0.9.8b-17.fc8.alpha [34056]
RPM Path:
/mnt/koji/packages/openssl/0.9.8b/17.fc8/alpha/openssl-0.9.8b-17.fc8.alpha.rpm
SRPM: openssl-0.9.8b-17.fc8 [12593]
SRPM Path:
/mnt/koji/packages/openssl/0.9.8b/17.fc8/src/openssl-0.9.8b-17.fc8.src.rpm
Built: Thu, 25 Oct 2007 04:36:26 CEST
Payload: fc0d712476cfa8d19984a7a96fc355f3
Size: 1625947
Build ID: 12593
And eg for dependencies:
[oliver@tuborg ~]$ koji call getRPMDeps 34056
[{'flags': 16384, 'name': '/bin/sh', 'type': 0,
'version': ''},
{'flags': 1344, 'name': '/sbin/ldconfig', 'type': 0,
'version': ''},
{'flags': 4416, 'name': '/sbin/ldconfig', 'type': 0,
'version': ''},
{'flags': 268435464,
'name': 'config(openssl)',
'type': 0,
'version': '0.9.8b-17.fc8'},
{'flags': 16384, 'name': 'libc.so.6.1', 'type': 0,
'version': ''},
{'flags': 16384, 'name': 'libc.so.6.1(GLIBC_2.0)',
'type': 0,
'version': ''},
{'flags': 16384, 'name': 'libc.so.6.1(GLIBC_2.1)',
'type': 0,
'version': ''},
{'flags': 16384,
'name': 'libc.so.6.1(GLIBC_2.1.3)',
'type': 0,
'version': ''},
{'flags': 16384, 'name': 'libc.so.6.1(GLIBC_2.3)',
'type': 0,
'version': ''},
{'flags': 16384,
'name': 'libc.so.6.1(GLIBC_2.3.4)',
'type': 0,
'version': ''},
{'flags': 16384, 'name': 'libc.so.6.1(GLIBC_2.4)',
'type': 0,
'version': ''},
{'flags': 16384, 'name': 'libcom_err.so.2', 'type': 0,
'version': ''},
{'flags': 16384, 'name': 'libcrypto.so.6', 'type': 0,
'version': ''},
{'flags': 16384, 'name': 'libdl.so.2.1', 'type': 0,
'version': ''},
{'flags': 16384, 'name': 'libdl.so.2.1(GLIBC_2.0)',
'type': 0,
'version': ''},
{'flags': 16384, 'name': 'libdl.so.2.1(GLIBC_2.1)',
'type': 0,
'version': ''},
{'flags': 16384, 'name': 'libgssapi_krb5.so.2', 'type':
0, 'version': ''},
{'flags': 16384, 'name': 'libk5crypto.so.3', 'type': 0,
'version': ''},
{'flags': 16384,
'name': 'libk5crypto.so.3(k5crypto_3_MIT)',
'type': 0,
'version': ''},
{'flags': 16384, 'name': 'libkrb5.so.3', 'type': 0,
'version': ''},
{'flags': 16384,
'name': 'libkrb5.so.3(krb5_3_MIT)',
'type': 0,
'version': ''},
{'flags': 16384, 'name': 'libresolv.so.2.1', 'type': 0,
'version': ''},
{'flags': 16384, 'name': 'libssl.so.6', 'type': 0,
'version': ''},
{'flags': 16384, 'name': 'libz.so.1', 'type': 0,
'version': ''},
{'flags': 0, 'name': 'mktemp', 'type': 0,
'version': ''},
{'flags': 16777290,
'name': 'rpmlib(CompressedFileNames)',
'type': 0,
'version': '3.0.4-1'},
{'flags': 16777290,
'name': 'rpmlib(PayloadFilesHavePrefix)',
'type': 0,
'version': '4.0-1'},
{'flags': 16384, 'name': 'rtld(GNU_HASH)', 'type': 0,
'version': ''},
{'flags': 268435464,
'name': 'config(openssl)',
'type': 1,
'version': '0.9.8b-17.fc8'},
{'flags': 32768, 'name': 'lib4758cca.so', 'type': 1,
'version': ''},
{'flags': 32768, 'name': 'libaep.so', 'type': 1,
'version': ''},
{'flags': 32768, 'name': 'libatalla.so', 'type': 1,
'version': ''},
{'flags': 32768, 'name': 'libchil.so', 'type': 1,
'version': ''},
{'flags': 32768, 'name': 'libcrypto.so.6', 'type': 1,
'version': ''},
{'flags': 32768, 'name': 'libcswift.so', 'type': 1,
'version': ''},
{'flags': 32768, 'name': 'libgmp.so', 'type': 1,
'version': ''},
{'flags': 32768, 'name': 'libnuron.so', 'type': 1,
'version': ''},
{'flags': 32768, 'name': 'libssl.so.6', 'type': 1,
'version': ''},
{'flags': 32768, 'name': 'libsureware.so', 'type': 1,
'version': ''},
{'flags': 32768, 'name': 'libubsec.so', 'type': 1,
'version': ''},
{'flags': 8, 'name': 'openssl', 'type': 1,
'version': '0.9.8b-17.fc8'}]
-of
8:04 a.m.
seth vidal wrote, at 12/17/2007 03:13 PM +9:00:
I've been working on a new version of createrepo that uses the
yum
modules to read in the package metadata. It's not really changing
createrepo fundamentally it just simplifies the code and reduces a lot
of duplication b/t createrepo and yum. However, one of the things that
comes out of this is the ability to create 'fake' yum package objects
comprised of data sucked directly out of koji.
The idea is that instead of getting a list of pkgs, getting the metadata
from them, then putting that metadata into the repodata xml format you
could just connect to koji with a list of specific packages you wanted,
request where the packages exist on disk (or a url to retrieve them) and
all the package metadata directly.
Is it related to this that currently
http://koji.fedoraproject.org/static-repos/dist-f9-build-current/ or
so are not accessible? I used to download rpms from here soon after
new rpms are rebuilt by yum.
Regards,
Mamoru
8:09 a.m.
On Mon, 2007-12-17 at 23:04 +0900, Mamoru Tasaka wrote:
seth vidal wrote, at 12/17/2007 03:13 PM +9:00:
> I've been working on a new version of createrepo that uses the yum
> modules to read in the package metadata. It's not really changing
> createrepo fundamentally it just simplifies the code and reduces a lot
> of duplication b/t createrepo and yum. However, one of the things that
> comes out of this is the ability to create 'fake' yum package objects
> comprised of data sucked directly out of koji.
>
> The idea is that instead of getting a list of pkgs, getting the metadata
> from them, then putting that metadata into the repodata xml format you
> could just connect to koji with a list of specific packages you wanted,
> request where the packages exist on disk (or a url to retrieve them) and
> all the package metadata directly.
>
Is it related to this that currently
http://koji.fedoraproject.org/static-repos/dist-f9-build-current/ or
so are not accessible? I used to download rpms from here soon after
new rpms are rebuilt by yum.
No, the buildsystem changes that took place yesterday evening are why
the static-repos are temporarily down.
Fedora Release Engineering is working on restoring them now.
~spot
5969
days inactive
5969
days old
3 comments
4 participants
participants (4)
-
Mamoru Tasaka -
Oliver Falk -
Seth Vidal -
Tom Callaway