Learn more about these different git repos.
Other Git URLs
I'd like the different editions to hit the mirrors differently, so I can get a better sense of the usage of each. The DNF team proposes this solution:
Dear Matthew, I would like to explain the solution little bit in more detail. We propose following: The package fedora-repos will be splitted into 3 packages (fedora-server-repos, fedora-workstations-repos, and fedora-cloud-repos). Each of them will have /etc/yum.repos.d/fedora.repo with modification in metalink, where you can use something like for fedora-workstations-repos: metalink=https://mirrors.fedoraproject.org/metalink?repo=fedora-debug- $releasever&arch=$basearch&releasevariant=workstation or for fedora-server-repos: metalink=https://mirrors.fedoraproject.org/metalink?repo=fedora-debug- $releasever&arch=$basearch&releasevariant=server That means that there will be no additional variable or requirement from dnf site, but only infrastructure solution. And this is exactly what you need, because your request is Fedora specific (cannot be applied for RHEL), therefore it has to be solved by Fedora delivery approach of distro variant. Hope that it helps.
Dear Matthew, I would like to explain the solution little bit in more detail. We propose following:
The package fedora-repos will be splitted into 3 packages (fedora-server-repos, fedora-workstations-repos, and fedora-cloud-repos). Each of them will have /etc/yum.repos.d/fedora.repo with modification in metalink, where you can use something like for fedora-workstations-repos:
metalink=https://mirrors.fedoraproject.org/metalink?repo=fedora-debug- $releasever&arch=$basearch&releasevariant=workstation
or for fedora-server-repos:
metalink=https://mirrors.fedoraproject.org/metalink?repo=fedora-debug- $releasever&arch=$basearch&releasevariant=server
That means that there will be no additional variable or requirement from dnf site, but only infrastructure solution. And this is exactly what you need, because your request is Fedora specific (cannot be applied for RHEL), therefore it has to be solved by Fedora delivery approach of distro variant. Hope that it helps.
What do you think?
Can't we autoinject the value of ID from /etc/os-release as a variable like osrelease_id? Then we wouldn't need separate files.
ID
/etc/os-release
osrelease_id
The downside is remixes that want to reuse the repos would need to carry overrides, perhaps we also autoinject osrelease_idlike and the metalink server would respond to either osrelease_id=fedora or osrelease_idlike=fedora.
osrelease_idlike
osrelease_id=fedora
osrelease_idlike=fedora
Also, what value would be used for the container base image?
That's what I originally asked for (Specifically "What I'd like is ID, VERSION_ID, and VARIANT_ID from /etc/os-release.") Yum had a feature for adding arbitrary variables; DNF does not. See https://bugzilla.redhat.com/show_bug.cgi?id=1251774 and upstream https://github.com/rpm-software-management/libdnf/issues/170.
It seems valuable for these to be categorized separately, too.
At present, it'd be fedora-NN, with no variant. It would be lovely to have the container base image use a different variant ID too, though.
fedora-NN
Adding "meeting" keyword, we will discuss about how mirror-manager works and other infra related issues and how it should be implemented in modularity world in our next Rel-Eng meeting on next Monday, June 26th 2017.
Metadata Update from @mohanboddu: - Issue tagged with: meeting
14:40 < dgilmore> #agreed releng feels that the most appropriate way forward is with the injection of a variable into the url
Metadata Update from @ausil: - Issue untagged with: meeting - Issue tagged with: f27
Metadata Update from @ausil: - Issue assigned to mohanboddu
@mohanboddu will review and update by next grooming meeting.
By the way, DNF now has support for arbitrary variables, but I'm not sure the support has been added to PackageKit-DNF yet.
Highly related: https://fedoraproject.org/wiki/Changes/Label_Our_Variants
@mohanboddu plans to talk with @sgallagh and others at FLOCK to discuss a plan, then implement before branching in mid August.
@mohanboddu reports that we accomplished this with the fedora-release package split (F29) but not the fedora-repos.
@mattdm, is this sufficient to close this ticket or do you also want this in fedora-repos?
Closing ticket since this is fixed. No advantage to do this in fedora-repos.
Metadata Update from @syeghiay: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.