Ticket #2387 (closed enhancement: wontfix)

Opened 4 years ago

Last modified 4 years ago

all-versions Koji repository

Reported by: jkratoch Owned by: ausil
Priority: major Milestone:
Component: Buildsys Version:
Severity: Normal Keywords:
Cc: Blocked By:
Blocking: Sensitive:

Description

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

Change History

comment:1 follow-up: ↓ 2 Changed 4 years ago by ausil

  • Status changed from new to closed
  • Resolution set to wontfix

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.

comment:2 in reply to: ↑ 1 Changed 4 years ago by jkratoch

  • Status changed from closed to reopened
  • Resolution wontfix deleted

Replying to 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.

comment:3 Changed 4 years ago by mmcgrath

  • Status changed from reopened to closed
  • Resolution set to wontfix

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

comment:4 Changed 4 years ago by jkratoch

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.

Note: See TracTickets for help on using tickets.