Bug 1211253

Are there any existing repositories that needs $foo and $bar (where {$foo, $bar} ∩ {$relesever, $basearch} == {}) on order to resolve their URLs?

Can be there since there is not such functionality supported yet? But if you take a look at:

/etc/yum.repos.d/fedora.repo
/etc/yum.repos.d/fedora-updates.repo
/etc/yum.repos.d/fedora-updates-testing.repo

you could recognize some patterns there.

For example the updates and update-testing differ more or less just in updates-{released,testing}, you could use some parameter to switch between these two.

But again, the original point in bug bug 1173107 was that the releasever parameter has prominent place without any substantial reason and as its turn out, it leads later to its abuse of this parameter. May be it is totally wrong to allow such parameter substitutions ...

(In reply to Vít Ondruch from comment #2)
> But again, the original point in bug bug 1173107 was that the releasever
> parameter has prominent place without any substantial reason and as its turn
> out, it leads later to its abuse of this parameter. May be it is totally
> wrong to allow such parameter substitutions ...

So, in the end, you don't need this feature?

> Can be there since there is not such functionality supported yet? But if you
> take a look at:
> 
> /etc/yum.repos.d/fedora.repo
> /etc/yum.repos.d/fedora-updates.repo
> /etc/yum.repos.d/fedora-updates-testing.repo
> 
> you could recognize some patterns there.
> 
> For example the updates and update-testing differ more or less just in
> updates-{released,testing}, you could use some parameter to switch between
> these two.

But users don't want to "switch between these two". They want to use different combinations of them. If you specify these repositories in one file using the variable, you won't be able to (easily) use/enable these repositories together.

Since there is no apparent need to specify $releasever in some generic way, let me handle this request as a request for an ability to specify custom variables.

(In reply to Radek Holy from comment #3)
> (In reply to Vít Ondruch from comment #2)
> > But again, the original point in bug bug 1173107 was that the releasever
> > parameter has prominent place without any substantial reason and as its turn
> > out, it leads later to its abuse of this parameter. May be it is totally
> > wrong to allow such parameter substitutions ...
> 
> So, in the end, you don't need this feature?

No, I don't have any real use case at my hand. This was just requested in context of bug 1173107

(In reply to Radek Holy from comment #4)
> Since there is no apparent need to specify $releasever in some generic way,
> let me handle this request as a request for an ability to specify custom
> variables.

If $releasever looses its prominent status this way, then this is perfect ;)

*** Bug 1251774 has been marked as a duplicate of this bug. ***

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Thank you very much for your request, but according to provided information that you don't have any real user-case I have to close it. Of course in case some real user-case appears, please don't hesitate to reopen the bug report.

*** This bug has been marked as a duplicate of bug 1251774 ***