Re: Mock, Rawhide and DNF
On Mon, Feb 16, 2015 at 08:56:59AM +0100, Miroslav Suchý wrote: On 02/14/2015 04:33 AM, Kevin Kofler wrote: IMHO, it is the job of the EPEL package of mock to disable the config_opts['package_manager'] = 'dnf' option in the shipped version of the Rawhide configs. But then you will not be warned that your results may differ from Koji. Since koji builds against RHEL and mock against CentOS, the results may differ regularly anyhow. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Mock, Rawhide and DNF
On Mon, 16 Feb 2015 16:05:35 +0100
Kevin Kofler kevin.kof...@chello.at wrote:
Miroslav Suchý wrote:
On 02/14/2015 04:33 AM, Kevin Kofler wrote:
IMHO, it is the job of the EPEL package of mock to disable the
config_opts['package_manager'] = 'dnf' option in the shipped version of
the Rawhide configs.
But then you will not be warned that your results may differ from Koji.
Surely that's a minor issue compared to the builds failing entirely! We need
to ship configs that work out of the box. If we cannot provide DNF for EPEL,
the EPEL-hosted configs must not require it.
To make sure I understand the issues here, let me restate (or sum up
as Inigo Montoya would say):
1. DNF is the preferred package management tool for F22+.
2. The EPEL mock configs for RHEL6 and RHEL7 hosts will *never* have dnf
available and must use yum to build packages.
3. Anyone building an F22+ package on a RHEL{6,7} system will have
different depsolving and possibly different results than someone
building the same package on a Fedora system.
If the above are correct and the only issue here is that we have
different depsolving with yum versus dnf, let's detect that we're
building a Fedora package on EPEL and print a warning to that effect. I
don't think it does us any good to ship a configuration that won't work
(i.e. setting config_opts['package_manager'] = 'dnf' on an EPEL host).
It's either that or fail the build immediately and I'm more in favor of
printing a warning and continuing.
Clark
pgpVhj0vaTiXo.pgp
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Mock, Rawhide and DNF
Clark Williams wrote:
If the above are correct and the only issue here is that we have
different depsolving with yum versus dnf, let's detect that we're
building a Fedora package on EPEL and print a warning to that effect. I
don't think it does us any good to ship a configuration that won't work
(i.e. setting config_opts['package_manager'] = 'dnf' on an EPEL host).
It's either that or fail the build immediately and I'm more in favor of
printing a warning and continuing.
Maybe the code should just do something like:
if config_opts['package_manager'] == 'dnf' and not have_dnf:
warning('dnf not found, falling back to yum')
warning('depsolving results may differ')
config_opts['package_manager'] = 'yum'
?
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Mock, Rawhide and DNF
On 02/14/2015 04:33 AM, Kevin Kofler wrote: IMHO, it is the job of the EPEL package of mock to disable the config_opts['package_manager'] = 'dnf' option in the shipped version of the Rawhide configs. But then you will not be warned that your results may differ from Koji. -- Miroslav Suchy, RHCE, RHCDS Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Mock, Rawhide and DNF
On Fri, Feb 13, 2015 at 09:35:30AM +0100, Miroslav Suchy wrote: Hi, I just released mock-1.2.7. It have - beside one small bug and new F22 configs - one important change. The rawhide configs have this one line included: config_opts['package_manager'] = 'dnf' which means that Mock will use DNF for building packages for rawhide targets. There are two consequences, which I would like to point out. This change is done only in Mock, but not in Koji. M.McLean is working on Koji code enhancement, which allow to do this change in Koji too. The ETA is 1-3 months. During this transient period Koji will use YUM for rawhide targets, while your local mock builds will use DNF. We would like to use this period to get broader testing of Mock+DNF before it reach Koji. If you experience some problem (I believe there will be none) please report it, so we can address it before we deploy this change on Koji. RHEL/EPEL users do not have DNF available, therefore they are unable to build packages for Fedora Rawhide. There is however a workaround. Just change this line: config_opts['package_manager'] = 'dnf' to this: config_opts['package_manager'] = 'yum' or you can simply delete it because Yum is the default. Or you can pass --yum to mock. Could it be an idea to check if /usr/bin/dnf exists (or if dnf can be found in $PATH) before calling dnf and if not a) warn the user and b) switch back to yum? This would make mock run out of the box for RHEL/EPEL users as well. Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Mock, Rawhide and DNF
On Friday, February 13, 2015, Pierre-Yves Chibon pin...@pingoured.fr wrote: On Fri, Feb 13, 2015 at 09:35:30AM +0100, Miroslav Suchy wrote: RHEL/EPEL users do not have DNF available, therefore they are unable to build packages for Fedora Rawhide. There is however a workaround. Just change this line: config_opts['package_manager'] = 'dnf' to this: config_opts['package_manager'] = 'yum' or you can simply delete it because Yum is the default. Or you can pass --yum to mock. Could it be an idea to check if /usr/bin/dnf exists (or if dnf can be found in $PATH) before calling dnf and if not a) warn the user and b) switch back to yum? This would make mock run out of the box for RHEL/EPEL users as well. Mock needs to check if /usr/bin/dnf is a file instead of a symlink as well since I've created a symlink on my system. (a little bit strange though) -- Yours sincerely, Christopher Meng http://cicku.me -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Mock, Rawhide and DNF
Hi, I just released mock-1.2.7. It have - beside one small bug and new F22 configs - one important change. The rawhide configs have this one line included: config_opts['package_manager'] = 'dnf' which means that Mock will use DNF for building packages for rawhide targets. There are two consequences, which I would like to point out. This change is done only in Mock, but not in Koji. M.McLean is working on Koji code enhancement, which allow to do this change in Koji too. The ETA is 1-3 months. During this transient period Koji will use YUM for rawhide targets, while your local mock builds will use DNF. We would like to use this period to get broader testing of Mock+DNF before it reach Koji. If you experience some problem (I believe there will be none) please report it, so we can address it before we deploy this change on Koji. RHEL/EPEL users do not have DNF available, therefore they are unable to build packages for Fedora Rawhide. There is however a workaround. Just change this line: config_opts['package_manager'] = 'dnf' to this: config_opts['package_manager'] = 'yum' or you can simply delete it because Yum is the default. Or you can pass --yum to mock. However you should be aware that you are using different depsolving and you may get slightly different result. And last one notice: I built mock-1.2.7 only for rawhide, F22 and F21 for now. I will create updates for F20, Epel7 and EL6 on Wednesday next week as I do not want to interrupt quarantine period of previous update in bodhi, which carry some important fixes. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Mock, Rawhide and DNF
On 13. 2. 2015 at 19:10:01, Christopher Meng wrote: On Friday, February 13, 2015, Pierre-Yves Chibon pin...@pingoured.fr wrote: On Fri, Feb 13, 2015 at 09:35:30AM +0100, Miroslav Suchy wrote: RHEL/EPEL users do not have DNF available, therefore they are unable to build packages for Fedora Rawhide. There is however a workaround. Just change this line: config_opts['package_manager'] = 'dnf' to this: config_opts['package_manager'] = 'yum' or you can simply delete it because Yum is the default. Or you can pass --yum to mock. Could it be an idea to check if /usr/bin/dnf exists (or if dnf can be found in $PATH) before calling dnf and if not a) warn the user and b) switch back to yum? This would make mock run out of the box for RHEL/EPEL users as well. Mock needs to check if /usr/bin/dnf is a file instead of a symlink as well since I've created a symlink on my system. (a little bit strange though) Not even this is going to be sufficient, as we plan to release a transition script /usr/bin/yum. This will be installed if people choose not to install yum and it will redirect user to /usr/bin/dnf, much like service redirects to systemctl. Thanks Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Mock, Rawhide and DNF
Pierre-Yves Chibon wrote: Could it be an idea to check if /usr/bin/dnf exists (or if dnf can be found in $PATH) before calling dnf and if not a) warn the user and b) switch back to yum? This would make mock run out of the box for RHEL/EPEL users as well. IMHO, it is the job of the EPEL package of mock to disable the config_opts['package_manager'] = 'dnf' option in the shipped version of the Rawhide configs. I don't care whether it's done using patch or sed, as long as it's done in SOME way. That's what packaging is for. The fact that Fedora happens to be upstream for this package doesn't mean it cannot be patched for specific releases (especially RHEL/EPEL). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
