#10191 epel/7/SRPMS no longer exists
Closed: Fixed 2 years ago by humaton. Opened 2 years ago by alexi.

Hello,

We just noticed that epel/7/SRPMS no longer exists as a repository, it seems to have been replaced with epel/7/source. The same thing happened to epel/8/*/SRPMS, but not to epel/next/8/Everything/SRPMS.

This is a big issue because all the epel-release packages point to the old location for the source RPMs, so all those repositories are currently broken.

We have fixed this temporarily for the linuxsoft.cern.ch/epel mirror by creating symlinks and stopping the synchronization, but it really requires a fix upstream.

Cheers,
Alex


Metadata Update from @mohanboddu:
- Issue tagged with: medium-gain, medium-trouble, ops

2 years ago

@adrian Can you fix MM to point to source/tree/ dir for srpms?

RE: https://pagure.io/fedora-infrastructure/issue/10017

I did the change a couple of hours ago.

https://mirrors.fedoraproject.org/metalink?repo=epel-source-7&arch=source

only returns epel/7/source/tree/repodata/repomd.xml.

I cannot close the ticket. But I think this should be solved.

Closing this tickets, thanks @adrian

Metadata Update from @mohanboddu:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

2 years ago

@adrian I just synced from dl-tier1 and there is still no SRPM directory for most of the repos. We need some symlinks between RPMS/ and source/tree/, otherwise all the repo configuration files currently in the wild will be broken.

Metadata Update from @alexi:
- Issue status updated to: Open (was: Closed)

2 years ago

@adrian I just synced from dl-tier1 and there is still no SRPM directory for most of the repos. We need some symlinks between RPMS/ and source/tree/, otherwise all the repo configuration files currently in the wild will be broken.

The repo configuration files should use the metalink and then it should just work. Are you using the metalink?

No, we are not, we point to our own mirror directly (https://linuxsoft.cern.ch/epel/). A symlink would be a backwards-compatible way of making this transition while we roll out new configuration files everywhere. (which will take quite a bit of time, given old docker and cloud images will continue to have the old repos...)

You need to talk to @mohanboddu then. I just adapted the metalinks to point to the new location.

Not sure if you thought about it for the future, but instead of changing repository files you could just add your mirror (as a private mirror) to MirrorManager and the metalink would redirect your clients to your mirror autmatically.

Not sure if you thought about it for the future, but instead of changing repository files you could just add your mirror (as a private mirror) to MirrorManager and the metalink would redirect your clients to your mirror autmatically.

This isn't really an option for us as many of our systems don't have external connectivity, so they wouldn't be able to talk to mirrors.fedoraproject.org. Plus, why have the extra hop?

Anyway, I hope @mohanboddu can help with this. For the time being, I've created the symlinks locally and stopped mirroring, but that's not a great solution (especially given that other people also mirror from us!)

We do not use symlinks on the master mirrors because in the past some mirrors do not support them. (AFS and other stanger filesystems).

No, we are not, we point to our own mirror directly (https://linuxsoft.cern.ch/epel/). A symlink would be a backwards-compatible way of making this transition while we roll out new configuration files everywhere. (which will take quite a bit of time, given old docker and cloud images will continue to have the old repos...)

Do note that this is just source rpms... do you use / download those very much? All other repos are completely unaffected. All people using metalink are unaffected.

I suppose we could hardlink SRPMS to source and delete SRPMS after some time to allow for transition. Would that work for you?

Do note that this is just source rpms... do you use / download those very much? All other repos are completely unaffected. All people using metalink are unaffected.

As far as I know, this is currently affecting us in the CI pipelines we use to build packages, as they use yum-builddep and that seems to enable the source repos automatically. If the repos are not in RPMS/ as before, then the jobs fail and the entire CI pipeline stops.

I suppose we could hardlink SRPMS to source and delete SRPMS after some time to allow for transition. Would that work for you?

Yes, this would be fine. We could then make the changes to our configuration files and hopefully everyone will upgrade soon.

By the way, was this change announced or discussed somewhere?

Why are we changing to /source/tree anyway?

Because thats what pungi does by default and is the way it is in all our releases/betas. It was causing confusion all the time that it was SRPMS for updates/epel and source for beta/GA releases. We could have changed it the other way, but thought 'source' was more clear than SRPMS anyhow and they would aline well now, instead of in a few years...

This is being discussed in the Fedora Releng meeting today

@kevin and @mohanboddu will fix this

From the releng meeting today, we decided to go and try symlinking /SRPMS to /source/tree, we will work on it asap.

From the releng meeting today, we decided to go and try symlinking /SRPMS to /source/tree, we will work on it asap.

@lenkaseg wants to help take a look at it

Metadata Update from @mohanboddu:
- Issue assigned to lenkaseg

2 years ago

May be related, I see that playground/8/Everything/$basearch/debug no longer has a repodata, it's now been moved to playground/8/Everything/$basearch/debug/tree. Is this a mistake, or is the mistake that all the other debug repos don't have a /tree?

LGTM, but it's missing /pub/epel/playground/8/Everything/.

Looks good to me. :)

@mohanboddu you ok to run it (if it also looks ok to you)

@lenkaseg That is looking good, I will run it now.

The symlinks have been created, hopefully that should fix all the issues.

Please reopen this ticket if the issue still persists.

Metadata Update from @mohanboddu:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

2 years ago

This seems to work fine, thanks @lenkaseg and @mohanboddu! Just two questions, though:

  1. I take it the plan is still to remove the symlinks at some point. When will that happen?

  2. What about the playground/8/Everything/$basearch/debug issue I mentioned earlier?

Metadata Update from @alexi:
- Issue status updated to: Open (was: Closed)

2 years ago
  1. I mailed mirror-admin list about it and noted the date there... "Tue 2021-08-10" which is f35 branching date. That gives about a month. Will that work for you?

  2. So, thats another difference between composes vs updates composes. Composes (GA/Beta/epel8-playground) use debug/tree and updates uses debug. I suppose we could fix this also, but after all the mess we caused with source/SRPMS, might be best to just leave that one. Especially since its not caused problems in the past.

  1. Sorry, I missed the email. It would be great to have the symlinks a bit longer to make sure everyone updates, but I hope it will be long enough.

  2. Ok, that's fine, I'll make sure we point to the right place. I just wanted to make sure this was intentional and not something else that was going to change soon.

Metadata Update from @alexi:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

2 years ago

@alexi Playground has been using source/tree since when it started, so it should be fine.

Metadata Update from @mohanboddu:
- Issue status updated to: Open (was: Closed)

2 years ago

Metadata Update from @humaton:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

2 years ago

Login to comment on this ticket.

Metadata
Boards 1
Ops Status: Backlog