11:56 p.m.
https://fedoraproject.org/wiki/Mock#Mock_on_EL_6_and_EL_7:_Yum.2C_and_DNF
I just ran into this issue and I was wondering if it's possible for this
flag to be add to the default config on RHEL 6/7.
Thanks,
Dave
7:19 a.m.
Dne 2.6.2015 v 06:56 Dave Johansen napsal(a):
https://fedoraproject.org/wiki/Mock#Mock_on_EL_6_and_EL_7:_Yum.2C_and_DNF
I just ran into this issue and I was wondering if it's possible for this flag to be
add to the default config on RHEL 6/7.
Technically yes.
Politically no.
As stated in refered blog entry:
http://miroslav.suchy.cz/blog/archives/2015/05/20/why_mock_does_not_work_...
I decided to go with 3rd option. And you must manually acknowledge that you are creating
builds non-standard way and
they may differ from builds made on Fedora.
--
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
9:31 a.m.
On Wed, 2015-06-03 at 14:19 +0200, Miroslav Suchý wrote:
Dne 2.6.2015 v 06:56 Dave Johansen napsal(a):
> https://fedoraproject.org/wiki/Mock#Mock_on_EL_6_and_EL_7:_Yum.2C_a
> nd_DNF
>
> I just ran into this issue and I was wondering if it's possible for
> this flag to be add to the default config on RHEL 6/7.
Technically yes.
Politically no.
As stated in refered blog entry:
http://miroslav.suchy.cz/blog/archives/2015/05/20/why_mock_does_not
_work_on_el_6_and_el7_and_how_to_fix_it/index.html
I decided to go with 3rd option. And you must manually acknowledge
that you are creating builds non-standard way and
they may differ from builds made on Fedora.
Except that builds made on Fedora Koji all use yum to populate the mock
chroot, not dnf.
As a result, it is the mock default configuration of using dnf which is
non-standard.
--
Mathieu
10:10 a.m.
On Wed, Jun 3, 2015 at 7:31 AM, Mathieu Bridon <bochecha(a)fedoraproject.org>
wrote:
On Wed, 2015-06-03 at 14:19 +0200, Miroslav Suchý wrote:
> Dne 2.6.2015 v 06:56 Dave Johansen napsal(a):
> > https://fedoraproject.org/wiki/Mock#Mock_on_EL_6_and_EL_7:_Yum.2C_a
> > nd_DNF
> >
> > I just ran into this issue and I was wondering if it's possible for
> > this flag to be add to the default config on RHEL 6/7.
>
> Technically yes.
>
> Politically no.
>
> As stated in refered blog entry:
> http://miroslav.suchy.cz/blog/archives/2015/05/20/why_mock_does_not
> _work_on_el_6_and_el7_and_how_to_fix_it/index.html
> I decided to go with 3rd option. And you must manually acknowledge
> that you are creating builds non-standard way and
> they may differ from builds made on Fedora.
I don't mean to start an argument and this is a question out of honest
curiosity. I'm not familiar with the details of yum or dnf's requires
resolution, but are there really ambiguities in the dependency tree that
have multiple resolutions that are "valid" (like the ruby example you list
in the blog post)?
Except that builds made on Fedora Koji all use yum to populate the
mock
chroot, not dnf.
As a result, it is the mock default configuration of using dnf which is
non-standard.
In my mind, "non-standard but works" is better than "standard but
broken".
Especially, when the error is a bit hard to decipher and tracking down a
solution can take a while (at least in my case it did). Basically, I think
that one of the following solutions would be helpful:
1) Change EL to default to using yum so it "just works", or
2) Change the error message on EL to indicate why it's not working and
where more info can be found.
Thanks,
Dave
10:17 a.m.
Dne 3.6.2015 v 17:10 Dave Johansen napsal(a):
I don't mean to start an argument and this is a question out of honest curiosity.
I'm not familiar with the details of
yum or dnf's requires resolution, but are there really ambiguities in the dependency
tree that have multiple resolutions
that are "valid" (like the ruby example you list in the blog post)?
Yes, there are.
Other example can be soft deps (which start to shown up in Fedora). Recommends are ignored
by Yum, while DNF install
them by default.
2) Change the error message on EL to indicate why it's not
working and where more info can be found.
*nod* This is something I can work on.
--
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
10:22 a.m.
On Wed, Jun 3, 2015 at 8:17 AM, Miroslav Suchý <msuchy(a)redhat.com> wrote:
Dne 3.6.2015 v 17:10 Dave Johansen napsal(a):
>
> I don't mean to start an argument and this is a question out of honest
curiosity. I'm not familiar with the details of
> yum or dnf's requires resolution, but are there really ambiguities in
the dependency tree that have multiple resolutions
> that are "valid" (like the ruby example you list in the blog post)?
Yes, there are.
Other example can be soft deps (which start to shown up in Fedora).
Recommends are ignored by Yum, while DNF install
them by default.
> 2) Change the error message on EL to indicate why it's not working and
where more info can be found.
*nod* This is something I can work on.
Great! That would be very helpful and much appreciated.
10:23 a.m.
Dne 3.6.2015 v 16:31 Mathieu Bridon napsal(a):
Except that builds made on Fedora Koji all use yum to populate the
mock
chroot, not dnf.
As a result, it is the mock default configuration of using dnf which is
non-standard.
In February, during DevConf.cz I talked with several rel-engs (namely dgilmore and
probinson).
And we agreed to first enable DNF in local Mock configs for F23 and get some feedback.
Basically to get some real world
testing before it is deployed in Koji. And it was promised to get this change to Koji some
time later - but still in F23
time-frame.
I believe this is worked on as I sent initial patch for Koji to builsys ML, but dgilmore
wanted to do that little bit
differently.
--
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
5:28 p.m.
Miroslav Suchý wrote:
Technically yes.
Politically no.
As stated in refered blog entry:
http://miroslav.suchy.cz/blog/archives/2015/05/20/why_mock_does_not_work_...
I decided to go with 3rd option. And you must manually acknowledge that
you are creating builds non-standard way and they may differ from builds
made on Fedora.
I find this to be a completely unacceptable attitude:
1. The software we ship in Fedora (and that includes EPEL) should work out
of the box. If you cannot provide DNF (with the plugins) in EPEL, then
defaulting to yum is the only option.
2. The mock previously in EPEL actually worked for Rawhide (using yum
there), so you have taken existing user setups that worked and broken
them, for no practical benefit whatsoever (because all they can do to
make it work is to make exactly the settings change you refuse to make by
default, and because mock will just work with yum).
You made a decision that was really not yours to make (because using DNF is
simply not possible on EL) and are forcing it on all EPEL users for, as you
admit, purely political reasons.
Kevin Kofler
1:56 a.m.
Dne 12.6.2015 v 00:28 Kevin Kofler napsal(a):
1. The software we ship in Fedora (and that includes EPEL) should
work out
of the box. If you cannot provide DNF (with the plugins) in EPEL, then
defaulting to yum is the only option.
2. The mock previously in EPEL actually worked for Rawhide (using yum
there), so you have taken existing user setups that worked and broken
them, for no practical benefit whatsoever (because all they can do to
make it work is to make exactly the settings change you refuse to make by
default, and because mock will just work with yum).
So you are suggesting what?
Let silently use yum on EL hosts? And let people think that they are getting the same
results as others get on Fedora,
while they get different results?
--
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
4:47 a.m.
On Mon, 2015-06-15 at 08:56 +0200, Miroslav Suchý wrote:
Dne 12.6.2015 v 00:28 Kevin Kofler napsal(a):
> 1. The software we ship in Fedora (and that includes EPEL) should
> work out of the box. If you cannot provide DNF (with the plugins)
> in EPEL, then defaulting to yum is the only option.
>
> 2. The mock previously in EPEL actually worked for Rawhide (using
> yum there), so you have taken existing user setups that worked and
> broken them, for no practical benefit whatsoever (because all they
> can do to make it work is to make exactly the settings change you
> refuse to make by default, and because mock will just work with
> yum).
So you are suggesting what?
Let silently use yum on EL hosts?
Kevin didn't say anything about it being silent.
By all means, do warn people that mock is going to use yum instead of
dnf as it should.
But an application should never print an error message telling the user
what they can do to get the error to go away. That's just bad design.
If the application knows what the user should do to get around the
error, then the application should just do it itself.
Finally, you're basically saying that mock requires dnf to build
"proper" Rawhide packages. You're a package maintainer, it is your
responsibility to maintain the dependencies for your package in all the
Fedora/EPEL branches where your package is.
That means if mock requires dnf (and its plugins) to build Rawhide
packages, and you maintain mock in EPEL, then it is your responsibility
to make sure that dnf (and its plugins) are in EPEL.
--
Mathieu
1:06 p.m.
2015-06-15 11:47 GMT+02:00 Mathieu Bridon <bochecha(a)fedoraproject.org>:
Kevin didn't say anything about it being silent.
By all means, do warn people that mock is going to use yum instead of
dnf as it should.
But an application should never print an error message telling the user
what they can do to get the error to go away. That's just bad design.
If the application knows what the user should do to get around the
error, then the application should just do it itself.
Finally, you're basically saying that mock requires dnf to build
"proper" Rawhide packages. You're a package maintainer, it is your
responsibility to maintain the dependencies for your package in all the
Fedora/EPEL branches where your package is.
That means if mock requires dnf (and its plugins) to build Rawhide
packages, and you maintain mock in EPEL, then it is your responsibility
to make sure that dnf (and its plugins) are in EPEL.
+1 for the last paragraph.
We need to fix this asap.
--
Mathieu
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
3262
days inactive
3276
days old
10 comments
5 participants
participants (5)
-
Dave Johansen -
Haïkel -
Kevin Kofler -
Mathieu Bridon -
Miroslav Suchý