#2387 all-versions Koji repository
Closed: Fixed None Opened 13 years ago by jkratoch.

= phenomenon =

I cannot prepare a mock root to contain the right NVRAs of all the packages as the Bug reporter has, to reproduce/analyse his problem/core files.

= reason =

There is no central database of build-id -> NVRA for older rpms which are no longer in the current official repository.

= recommendation =

Could Koji provide all the available versions of packages in a repository?

Even http://koji.fedoraproject.org/static-repos/ indexes only the latest package versions there. Also f14 is not available there.

fedora devel post: http://lists.fedoraproject.org/pipermail/devel/2010-September/142701.html

Dennis Gregorovic's agreement: http://lists.fedoraproject.org/pipermail/devel/2010-September/142715.html


the static repos you reference have been long deprecated. koji itself has a better solution
http://koji.fedoraproject.org/repos/<buildtag>/latest/ that gets updated on every newRepo task.

though it wont help you unless the build your looking for has been explicitly tagged into the buildroot.

your proposal is not really feasable. for one koji repos exclude debug rpms. the information your wanting is not stored in kojis database so its not queryable. how do we deal with deleted rpms? how do we break things up. if we put all current koji builds into a single repo the repodata would be massive. downloading it would take alot of time, and people would complain. managing it and updating would take a long long time we have ~ 6-7T of rpms in koji.

The correct thing to do would be to have the reporter redo his/her test and get a core using the current available version. since the issue could already be fixed. if they used a newer version from koji then they should say so and you can manually add the version needed.

Replying to [comment:1 ausil]:

though it wont help you unless the build your looking for has been explicitly tagged into the
buildroot.

This ticket is about all the versions, incl. the older ones.

your proposal is not really feasable. for one koji repos exclude debug rpms.

I such case there should be a different repo including debug rpms (or this one should be changed).

how do we deal with deleted rpms?

That's a question. So far it would be OK to ignore them as one cannot download them anyway.

It would be best to at least keep their build-ids. Whether as some minimal/stub .rpms or whether as just some artificial yum repo db records is a question.

An alternative light-weight way (requiring coding new client side yum-like tools) is to just keep a non-yum database of the build-ids, the second item mentioned in the mail post:
http://lists.fedoraproject.org/pipermail/devel/2010-September/142701.html

if we put all current koji builds into a single repo the repodata would be massive.
downloading it would take alot of time, and people would complain.

There could be separate repositories for each day so one can download them incrementally.
I would rather keep my machine downloading it for the whole night than trying to cherry-pick them myself for the whole day.

The correct thing to do would be to have the reporter redo his/her test

Many times the problem is not easily reproducible. Also the reporters are often not willing to workaround Fedora infrastructure defects.

and get a core using the current available version.

With Fedora daily updates there is never "the current version". Also I do not have time to deal with the bug the exact date it got reported. And when I get to it the packages are no longer available again. That's a never ending chase.

since the issue could already be fixed.

As a part of the upstream GDB development I am aware which bug is / is not being fixed.

they should say so and you can manually

Yes, I have been already wasting many my engineering hours doing it all manually in the past years. This is the reason I filed this ticket.

This really is closed "wontfix" we won't be doing this.

F13 Everything x86_64 is IIRC ~16GB, its repodata is 71MB. If all the Koji packages are 7TB:
7000/16*71 = 31 GB of all-versions repodata.

As each build day (week?) can have its own repository they can be downloaded incrementally. 31GB of indexes is fine with me.

OTOH I understand it would be better if yum supported a special index just for build-ids which would have much more manageable size, for both the server and the client side.

Login to comment on this ticket.

Metadata