Bug 1173107

Hello, thank you for the report.
I have been pretty sure that YUM also requires you to specify --releasever when you use --installroot but I found out that it's just recommended.

DNF uses "releasever" not just for the ".repo" files substitution and thus it somehow depends on it. For example, it's used in the path of the cache. I find it funny that if you don't provide a "releasever" to YUM in this case, the resulting cache path is "/var/cache/yum/x86_64/\$releasever/" :-) On the other hand, it's probably the safest solution...

Anyway, I see that it's a little uncomfortable to be forced to set it in the cases when your input does not contain such a variable (I mean none of your ".repo" files contain "$releasever"). We'll take a look. However, I think it's not so critical since it can be easily worked around.

This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle.
Changing version to '22'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22

Since this is more about how mock isn't working, I think it best to triage it there initially (feel free to reassign back if there are plans underway to fix this in dnf )

(In reply to Rex Dieter from comment #3)
Although I initially found the issue due to testing mock, this is definitely DNF issue. There is no particular reason to specify $releasever as I demonstrated in my initial comment.

Moreover if I am not mistaken, mock now specifies $releasever in its config files due to this issue.

Latest mock-1.2.7-1 releases are (still) broken, that's why I reassigned it there.

(In reply to Rex Dieter from comment #5)
> Latest mock-1.2.7-1 releases are (still) broken, that's why I reassigned it
> there.

Are you sure you run "rpmconf" after installation? All my mock configs contains releasever specified (I checked F21-Rawhide, x86_64) and I am sure I don't have modified configs.

No, I didn't run rpmconf, shouldn't mock 'just work' ?

It just works if you are using upstream mock configuration files. And these files have to unfortunately hotfix this DNF issue.

Nevermind, I do see releasever referenced now during 'mock init' calls, sorry for the noise.

Since I think about this issue now, may be DNF should use the --installroot option for unique cache. E.g. if I specify "--installroot /var/lib/mock/ruby22-rhel-7/root/", the cache path could look like "/var/cache/dnf/var/lib/mock/ruby22-rhel-7/root/". The --releasever parameter should be used just for expansion of config parameters.

Moreover, not sure why this is so exceptional parameter. There should be probably more universal way to be able to specify more configuration parameters then just $releasever and $basearch

(In reply to Vít Ondruch from comment #10)
> Since I think about this issue now, may be DNF should use the --installroot
> option for unique cache. E.g. if I specify "--installroot
> /var/lib/mock/ruby22-rhel-7/root/", the cache path could look like
> "/var/cache/dnf/var/lib/mock/ruby22-rhel-7/root/". The --releasever
> parameter should be used just for expansion of config parameters.

Maybe I miss some details but I guess that reason for having different cache paths for different "releasever" is to avoid cache conflicts. I mean, if I have a repo that contains this variable and I run "dnf --releasever=21" first, and then "dnf --releasever=22", I don't want DNF to use the cache for F21. So, I don't think that the suggestion for having cache paths derived (only) from "--installroot" is good because you can still call "dnf --installroot=/path --releasever=21" and then "dnf --installroot=/path --releasever=22". In your case, it's safe. In other cases, it may be unsafe.

This is definitely not mock issue.
Since mock-1.1.36 (and bug 1056039) there is logic in mock that basically does:
        releasever = self.config['releasever']
        if releasever:
            invocation += ['--releasever', releasever]

And since that time every config of mock ships with:
  config_opts['releasever'] = '21'
with corresponding number.

If you have mock-1.1.36 or newer and you do not have this option there, then you in past touched that config and rpm created .rpmnew files on your disk.
You should manually merge it. Or use rpmconf to assist you with this process.

(In reply to Radek Holy from comment #11)
Well, you are right. So I played with the --releasever and observed what does mock and what does DNF and what is cached where

I place my conclusions first here, since the reasoning is a bit longer:

1) Please drop the $basearch and $releasever from the cache directory structure, since they can't protect anything.

2) Please don't enforce --releasever flag, since even though it is specified, it might have no sense. I such case, unexpanded $releasever variable does the same service.

3) Optionally, provide some mechanism, which would replace --releasever parameter in some generic way, e.g. let me use also $foo and $bar variables in my DNF configuration files and let me specify them on command line.



And now, please me explain.


Your point is that if you once specify --releasever=21 and later --releasever=22, then you might be in some troubles. That is nice, you are thinking about some isolated environment where you have everything under control. However, what happens if your configuration file is referring to my repository, which is hosted somewhere on my server and I will do some nasty things to the repository. I might release modified version of some package with the same NVR, I might completely change the content of repository etc. From that POV, you can't be sure about the content of the cache.

Moreover, just a few examples how convoluted the DNF(YUM) behavior in this regard is:

1. Specify just --installroot

# dnf --installroot ~/dnf-test install ruby --disablerepo=* --enablerepo=fedora --releasever 1987
Error: Failed to synchronize cache for repo 'fedora' from 'https://mirrors.fedoraproject.org/metalink?repo=fedora-1987&arch=x86_64': Cannot prepare internal mirrorlist: file "repomd.xml" was not found in metalink

Please note that weird --releasever I specified. You see that DNF fails no matter if I specified some weird releasever or it would stay unexpanded to $releasever (something what YUM probably does - ironically, I can do also '--releasever \$releasever' to emulate YUM's behavior ;)) and now lets see what DNF created:

$ find /home/vondruch/dnf-test/ -type d
/home/vondruch/dnf-test/
/home/vondruch/dnf-test/var
/home/vondruch/dnf-test/var/cache
/home/vondruch/dnf-test/var/cache/dnf
/home/vondruch/dnf-test/var/cache/dnf/x86_64
/home/vondruch/dnf-test/var/cache/dnf/x86_64/21
/home/vondruch/dnf-test/var/cache/dnf/x86_64/21/x86_64
/home/vondruch/dnf-test/var/cache/dnf/x86_64/21/x86_64/1987

Ups, what is that x86_64/21 there, where did it come from? Why is is there duplicated?

2. What mock does?

$ cat /var/lib/mock/fedora-rawhide-x86_64/root/etc/dnf/dnf.conf | grep cache
cachedir=/var/cache/yum
keepcache=1

Mock puts dnf.conf into --install root. DNF in that case respects the cachedir configuration option and stores its cache there, so it does not conflict with system cache.

3. What happened on my system I updated from F20 -> F21?

$ ls -l /var/cache/dnf/x86_64/
celkem 16
drwxr-xr-x. 45 root root 12288 25. lis 15.27 20
drwxr-xr-x. 21 root root  4096 18. úno 13.13 21

Hups, this is rather unexpected. Why I have two versioned folders there? The "20" folder is abandoned and it just waste space on my system.

4. How does it look for Rawhide?

$ ls -l /var/cache/dnf/x86_64/
celkem 12
drwxr-xr-x. 2 root root 4096 22. říj 15.31 21
drwxr-xr-x. 5 root root 4096 26. úno 12.42 22
drwxr-xr-x. 3 root root 4096 26. úno 12.51 23

Ah, 3 cache folders and they will just grow, but the repository was always the same:

$ cat /etc/yum.repos.d/fedora-rawhide.repo | grep repo=rawhide\&
metalink=https://mirrors.fedoraproject.org/metalink?repo=rawhide&arch=$basearch

So why there are still versioned cache directories? This wastes precious space on my test virtual machine :/

(In reply to Vít Ondruch from comment #13)
> (In reply to Radek Holy from comment #11)
> Well, you are right. So I played with the --releasever and observed what
> does mock and what does DNF and what is cached where
> 
> I place my conclusions first here, since the reasoning is a bit longer:
> 
> 1) Please drop the $basearch and $releasever from the cache directory
> structure, since they can't protect anything.

Please, file a separate RFE with a reasonable explanation there. Anyway, the cache structure is something internal to DNF and I doubt you should request something like that. You should rather request fixing some problems (see my comments to the problems you've mentioned below).

> 2) Please don't enforce --releasever flag, since even though it is
> specified, it might have no sense. I such case, unexpanded $releasever
> variable does the same service.

IIUIC, this is what was requested originally and we have already confirmed that we'll take a look.

> 3) Optionally, provide some mechanism, which would replace --releasever
> parameter in some generic way, e.g. let me use also $foo and $bar variables
> in my DNF configuration files and let me specify them on command line.

Please, file a separate RFE with a real use case there.

> 
> 
> 
> And now, please me explain.
> 
> 
> Your point is that if you once specify --releasever=21 and later
> --releasever=22, then you might be in some troubles. That is nice, you are
> thinking about some isolated environment where you have everything under
> control. However, what happens if your configuration file is referring to my
> repository, which is hosted somewhere on my server and I will do some nasty
> things to the repository. I might release modified version of some package
> with the same NVR, I might completely change the content of repository etc.
> From that POV, you can't be sure about the content of the cache.

Yes, DNF is based on the assumption that the repositories have some properties. If you find out that there are some Fedora repositories that does not match the assumptions, please file a bug.

> Moreover, just a few examples how convoluted the DNF(YUM) behavior in this
> regard is:
> 
> 1. Specify just --installroot
> 
> # dnf --installroot ~/dnf-test install ruby --disablerepo=*
> --enablerepo=fedora --releasever 1987
> Error: Failed to synchronize cache for repo 'fedora' from
> 'https://mirrors.fedoraproject.org/metalink?repo=fedora-1987&arch=x86_64':
> Cannot prepare internal mirrorlist: file "repomd.xml" was not found in
> metalink
> 
> Please note that weird --releasever I specified. You see that DNF fails no
> matter if I specified some weird releasever or it would stay unexpanded to
> $releasever (something what YUM probably does - ironically, I can do also
> '--releasever \$releasever' to emulate YUM's behavior ;)) and now lets see
> what DNF created:
> 
> $ find /home/vondruch/dnf-test/ -type d
> /home/vondruch/dnf-test/
> /home/vondruch/dnf-test/var
> /home/vondruch/dnf-test/var/cache
> /home/vondruch/dnf-test/var/cache/dnf
> /home/vondruch/dnf-test/var/cache/dnf/x86_64
> /home/vondruch/dnf-test/var/cache/dnf/x86_64/21
> /home/vondruch/dnf-test/var/cache/dnf/x86_64/21/x86_64
> /home/vondruch/dnf-test/var/cache/dnf/x86_64/21/x86_64/1987
> 
> Ups, what is that x86_64/21 there, where did it come from? Why is is there
> duplicated?

What is the version of your DNF installation? Less than dnf-0.6.5-1.fc22? See bug 1194685, please.

> 2. What mock does?
> 
> $ cat /var/lib/mock/fedora-rawhide-x86_64/root/etc/dnf/dnf.conf | grep cache
> cachedir=/var/cache/yum
> keepcache=1
> 
> Mock puts dnf.conf into --install root. DNF in that case respects the
> cachedir configuration option and stores its cache there, so it does not
> conflict with system cache.
> 
> 3. What happened on my system I updated from F20 -> F21?
> 
> $ ls -l /var/cache/dnf/x86_64/
> celkem 16
> drwxr-xr-x. 45 root root 12288 25. lis 15.27 20
> drwxr-xr-x. 21 root root  4096 18. úno 13.13 21
> 
> Hups, this is rather unexpected. Why I have two versioned folders there? The
> "20" folder is abandoned and it just waste space on my system.
> 
> 4. How does it look for Rawhide?
> 
> $ ls -l /var/cache/dnf/x86_64/
> celkem 12
> drwxr-xr-x. 2 root root 4096 22. říj 15.31 21
> drwxr-xr-x. 5 root root 4096 26. úno 12.42 22
> drwxr-xr-x. 3 root root 4096 26. úno 12.51 23
> 
> Ah, 3 cache folders and they will just grow, but the repository was always
> the same:
> 
> $ cat /etc/yum.repos.d/fedora-rawhide.repo | grep repo=rawhide\&
> metalink=https://mirrors.fedoraproject.org/
> metalink?repo=rawhide&arch=$basearch
> 
> So why there are still versioned cache directories? This wastes precious
> space on my test virtual machine :/

Yes, this may be a problem. Please, file a bug if you can.

> Your point is that if you once specify --releasever=21 and later --releasever=22, then you might be in some troubles

Nope the point of this bugzilla is that DNF print error that "releasever" was not passed neither on commandline nor in config. Despite the fact that is will not be used at all later by DNF.
I assume that converting this error to warning would resolve this bug report.

> 3. What happened on my system I updated from F20 -> F21?

This is merely thing of upgrade tool to handle this and probably delete old cache. (fedora-upgrade do that, not sure about fed-up).


Also note That I may want to have various directories in /var/cache/dnf/x86_64/
Simply because I (being on F21) want to install something from F22 by doing
  dnf install --releasever 22  some-package-from-f22
And I do not want DNF to overwrite my current metadata in cache.
I am doing that quite often and noticed that other people is doing that too.

(In reply to Radek Holy from comment #14)

> > 1. Specify just --installroot
> > 
> > # dnf --installroot ~/dnf-test install ruby --disablerepo=*
> > --enablerepo=fedora --releasever 1987
> > Error: Failed to synchronize cache for repo 'fedora' from
> > 'https://mirrors.fedoraproject.org/metalink?repo=fedora-1987&arch=x86_64':
> > Cannot prepare internal mirrorlist: file "repomd.xml" was not found in
> > metalink
> > 
> > Please note that weird --releasever I specified. You see that DNF fails no
> > matter if I specified some weird releasever or it would stay unexpanded to
> > $releasever (something what YUM probably does - ironically, I can do also
> > '--releasever \$releasever' to emulate YUM's behavior ;)) and now lets see
> > what DNF created:
> > 
> > $ find /home/vondruch/dnf-test/ -type d
> > /home/vondruch/dnf-test/
> > /home/vondruch/dnf-test/var
> > /home/vondruch/dnf-test/var/cache
> > /home/vondruch/dnf-test/var/cache/dnf
> > /home/vondruch/dnf-test/var/cache/dnf/x86_64
> > /home/vondruch/dnf-test/var/cache/dnf/x86_64/21
> > /home/vondruch/dnf-test/var/cache/dnf/x86_64/21/x86_64
> > /home/vondruch/dnf-test/var/cache/dnf/x86_64/21/x86_64/1987
> > 
> > Ups, what is that x86_64/21 there, where did it come from? Why is is there
> > duplicated?
> 
> What is the version of your DNF installation? Less than dnf-0.6.5-1.fc22?
> See bug 1194685, please.

$ rpm -q dnf
dnf-0.6.4-1.fc21.noarch

So this might be resolved

(In reply to Miroslav Suchý from comment #15)
> > Your point is that if you once specify --releasever=21 and later --releasever=22, then you might be in some troubles
> 
> Nope the point of this bugzilla is that DNF print error that "releasever"
> was not passed neither on commandline nor in config. Despite the fact that
> is will not be used at all later by DNF.
> I assume that converting this error to warning would resolve this bug report.

Well, this would help but as I tried to explain in comment 13, I believe that the whole topic would deserve more attention then just converting error to warning. This whole think is to Fedora specific. It does not reflect my needs as packager nor it reflect needs of some 3rd party repositories, since their organization is unknown.

> > 3. What happened on my system I updated from F20 -> F21?
> 
> This is merely thing of upgrade tool to handle this and probably delete old
> cache. (fedora-upgrade do that, not sure about fed-up).
> 
> 
> Also note That I may want to have various directories in
> /var/cache/dnf/x86_64/
> Simply because I (being on F21) want to install something from F22 by doing
>   dnf install --releasever 22  some-package-from-f22
> And I do not want DNF to overwrite my current metadata in cache.
> I am doing that quite often and noticed that other people is doing that too.

If you go and modify the config file, if you download updated version of configuration file, this might happen to you as well. There is no protection.

IMO, the only correct way is to create new .repo file with correct configuration.

(In reply to Miroslav Suchý from comment #15)
> Also note That I may want to have various directories in
> /var/cache/dnf/x86_64/
> Simply because I (being on F21) want to install something from F22 by doing
>   dnf install --releasever 22  some-package-from-f22
> And I do not want DNF to overwrite my current metadata in cache.
> I am doing that quite often and noticed that other people is doing that too.

Also 'dnf --releasever=22 list' is used very often (or 'dnf repoquery' if you want).

(In reply to Vít Ondruch from comment #16)
> If you go and modify the config file, if you download updated version of
> configuration file, this might happen to you as well. There is no protection.
> 
> IMO, the only correct way is to create new .repo file with correct
> configuration.

Once you hit this situation in a real workflow, file a bug please.

Would it be possible to check that $releasever is specified in some of enabled repositories and fail in that case and otherwise just continue? And if the $releasever is not specified, then just don't use the $releasever directory in cache directory structure (or use empty string which should be essentially the same)?

This also affects koji-builder (kojid) which generates mock configs without 'releasever'.

Use case:
We have test that is evaluating behaviour of install scriptlets of our package. Test calls:
# yum -y --installroot=/tmp/tmp.fChG2xwyDj install cyrus-sasl

which is failing on f22/rawhide with mentioned message:
> Config error: releasever not given and can not be detected from the installroot.

Yum worked fine and current releasever was used by default. I don't see the reason why dnf is not working like yum in this case.

Config file is not everywhere like when you are using mock. DNF should be also friendly to ad-hoc queries and be somehow user-friendly, not letting user specify all the defaults config values on commandline.

(In reply to Dan Callaghan from comment #20)
> This also affects koji-builder (kojid) which generates mock configs without
> 'releasever'.

Indeed, this is the 'real use case' here. Koji doesn't has the concept or releasever because each of it's external repository are already versioned.( the only accepted macro is arch here).

Instead I guess dnf makes an even more false assumption that taking the host repository configuration can be derived to find the target repos.

I don't know why releasever was introduced into mock cfg files (probably to avoid to deviate from original config files). But It probably wrong to assume every config file will need this very specific macro.

FYI I've tried to set the releasever as 22 to workaround the issue and It's still cannot initiate a buildroot  (missing build group informations from root.log)
---
DEBUG util.py:378:  Yum command has been deprecated, redirecting to '/usr/bin/dnf --installroot /var/lib/mock/arm-f20-free-build-4232-5143/root/ --releasever 20 groupinstall build --setopt=tsflags=nocontexts'.
DEBUG util.py:378:  See 'man dnf' and 'man yum2dnf' for more information.
DEBUG util.py:378:  To transfer transaction metadata from yum to DNF, run:
DEBUG util.py:378:  'dnf install python-dnf-plugins-extras-migrate && dnf-2 migrate'
DEBUG util.py:378:  Last metadata expiration check performed 0:00:02 ago on Sun May 31 23:07:31 2015.
DEBUG util.py:378:  Warning: Group 'build' does not exist.
DEBUG util.py:378:  Dependencies resolved.
DEBUG util.py:378:  Operation aborted.
DEBUG util.py:388:  Is this ok [y/N]: 
DEBUG util.py:489:  Child return code was: 1
DEBUG util.py:171:  kill orphans
DEBUG util.py:509:  child environment: None
---

Reverting to yum-deprecated has workarounded the issue.

I meant 20 (root.log shown is for fedora 20) and 22 when relevant.
FYI I'm on a wandboard quad installed from fedora 22 GA.

In the Koji workflow, requiring releasever does not make much sense (the repositories may not correspond to any particular release). If we are to use dnf to generate build environments in Koji, then dnf should not be throwing this error.

Seems like the thing to do is either:
1) wait until the value is actually used before failing
2) determine if the value is needed before failing

Fixed as a part of
https://github.com/rpm-software-management/dnf/pull/309

dnf-1.0.2-2.fc22,hawkey-0.5.9-2.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/dnf-1.0.2-2.fc22,hawkey-0.5.9-2.fc22

Package dnf-1.0.2-3.fc22, hawkey-0.5.9-3.fc22:
* should fix your issue,
* was pushed to the Fedora 22 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing dnf-1.0.2-3.fc22 hawkey-0.5.9-3.fc22'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-12577/dnf-1.0.2-3.fc22,hawkey-0.5.9-3.fc22
then log in and leave karma (feedback).

As of dnf-1.0.2-3 bug 1173107 is still unfixed for F22. It does not give an error that --releasever is missing but instead fails to parse it to the url string.

Command used: 
sudo dnf --installroot /home/kinokoio/Filesystems/F23_KDE/ --disablerepo=updates-testing group install "KDE Plasma Workspaces

Output:
Error: Failed to synchronize cache for repo 'fedora' from 'https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=x86_64': Cannot prepare internal mirrorlist: file "repomd.xml" was not found in metalink

(In reply to Ivan Pacheco from comment #29)
> As of dnf-1.0.2-3 bug 1173107 is still unfixed for F22. It does not give an
> error that --releasever is missing but instead fails to parse it to the url
> string.
> 
> Command used: 
> sudo dnf --installroot /home/kinokoio/Filesystems/F23_KDE/
> --disablerepo=updates-testing group install "KDE Plasma Workspaces
> 
> Output:
> Error: Failed to synchronize cache for repo 'fedora' from
> 'https://mirrors.fedoraproject.org/metalink?repo=fedora-
> $releasever&arch=x86_64': Cannot prepare internal mirrorlist: file
> "repomd.xml" was not found in metalink

I can't speak for DNF upstream, but this is acceptable (although not the best) solution for me.

You are using configuration file with $releasever variable and you have not specified it. So DNF does not substitute it and hence fails. It could issue warning and fail, but the result would be the same. The solution is to add "--releasever=23" parameter on the command line.

dnf-1.0.2-3.fc22, hawkey-0.5.9-3.fc22 has been pushed to the Fedora 22 stable repository.  If problems still persist, please make note of it in this bug report.

Can we plase get a build with this fixed for f21. we can not move to using dnf to installing rawhide chroots until this is fixed in f21 as that is the builder OS

dnf-0.6.4-6.fc21 has been submitted as an update to Fedora 21. https://bodhi.fedoraproject.org/updates/FEDORA-2015-14323

dnf-0.6.4-6.fc21 has been pushed to the Fedora 21 testing repository. If problems still persist, please make note of it in this bug report.\nIf you want to test the update, you can install it with \n su -c 'yum --enablerepo=updates-testing update dnf'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-14323

dnf-0.6.4-7.fc21 has been submitted as an update to Fedora 21. https://bodhi.fedoraproject.org/updates/FEDORA-2015-9bcdcdc46b

dnf-0.6.4-7.fc21 has been pushed to the Fedora 21 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
$ su -c 'dnf --enablerepo=updates-testing update dnf'
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-9bcdcdc46b

dnf-0.6.4-7.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.

All Fedoras have still the same results:
# dnf -y --installroot=/tmp/tmp.fChG2xwyDj install cyrus-sasl
[...]
Error: Failed to synchronize cache for repo 'fedora' from 'https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=x86_64': Cannot prepare internal mirrorlist: file "repomd.xml" was not found in metalink

Now there is no error as before, but the variable $releasever is not translated in the paths if it is not specified on command-line. The same report as in comment #21.
Is this really expected behaviour? Is there any reason why is NOT used releasever as for normal dnf operations without installroot? Can some dnf developer explain us?
Is there any simple workaround when I want to do just the same what I was able to do with yum without harcoding releasever into tests?