#6847 Splitting fedora-repos into edition-specific variants (F27 timeframe)
Closed: Fixed 5 years ago Opened 6 years ago by mattdm.

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.

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.

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.

Also, what value would be used for the container base image?

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.

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.

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.

It seems valuable for these to be categorized separately, too.

Also, what value would be used for the container base image?

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.

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

6 years ago

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

6 years ago

Metadata Update from @ausil:
- Issue assigned to mohanboddu

6 years ago

@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.

@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)

5 years ago

Login to comment on this ticket.

Metadata