#136 Optionally create .repo files
Closed: Insufficient data 6 years ago Opened 9 years ago by lsedlar.

Pungi creates a YUM repo for each variant. It might be convenient to create a .repo file for these repos.

(This is an internal request RCMPROJ-5514.)


Would the .repo file contain an absolute URL?
In that case it's out of scope of pungi.
Maybe we should move it to compose-tools as
compose-create-repo-file(s) <compose> <baseurl>

Looks like pungi/phases/osbs.py is doing something like this already. The .repo files from that osbs phase are in the work dir, so I'm not sure what the stability guarantee is there. (I assume the work file/directory layout is considered internal to Pungi, and other tools should not rely on that layout?)

You are correct that the file in work is really just an implementation detail. The main problem with providing the file is that while we know where the compose is created, it may very well be moved after finishing. That would invalidate all .repo files.

Fedora does not move the composes as a whole, but internally there are workflows for moving the compose to another location once it passes some level of testing.

With regards to paths changing, for the OSBS use case, this is irrelevant because the image build will run before the compose finishes so there's no chance it will move in that time. But for the general use case of having a repo file, both internally and in fedora we move composes on occasion. Internally we use compose-promote (distill/pungi-utils) to move a compose. If compose-promote was updated to take into account the similar translate_path logic, and was expanded to be able to move across filesystems, it might be able to include an update_repofiles task to update those files while it's moved.

I'm liking @dmach's idea of a separate utilitycompose-create-repo-file. I have some code that can do this at https://github.com/red-hat-storage/bucko/blob/master/bucko/repo_compose.py

It's been a while since this issue was filed, and nothing happened here. I'm going to close this issue to clear the backlog.

Metadata Update from @lsedlar:
- Issue close_status updated to: Insufficient data
- Issue status updated to: Closed (was: Open)

6 years ago

Log in to comment on this ticket.

Metadata