2:40 p.m.
There's some confusion around this, so I thought I would post to try
and clear up things. In the event I am wrong on any of the below, please
do feel free to correct me. ;)
In the past the proposal was to have a yum-dnf package that provided
/usr/bin/yum, called dnf and conflicted with the yum package. I was
against that plan, but I think the one we settled on is worth doing.
It's somewhat of a middle ground between "yum is gone right now,
deal with it" and "you can keep using yum forever".
For f22 (and rawhide):
* dnf is installed by default. By that I mean it is in the 'core' group
in comps.
* dnf-yum is installed by default. By that I mean it is in the 'core'
group in comps next to dnf.
* yum is installed if something that depends on yum pulls it in or say
a user installs it manually.
* yum requires dnf-yum. So, if you install yum manually you will also
pull in dnf-yum (and the dnf plugin that handles history migrate).
* When you run 'yum' you get:
% sudo yum list foobar
Yum command has been deprecated, use dnf instead.
See 'man dnf' and 'man yum2dnf' for more information.
To transfer transaction metadata from yum to DNF, run 'dnf migrate'
Redirecting to '/usr/bin/dnf list foobar'
...then the ouput from dnf list foobar...
* If you wish to still use yum, the yum package provides now
a /usr/bin/yum-deprecated command that is the old yum
command renamed. It also has the notice message as above
on it.
* If you are using the yum python bindings directly, that will continue
to work if you have the yum package installed.
Note that this landed before Beta freeze, but there were some issues
with the initial package doing this. There is an update available:
https://admin.fedoraproject.org/updates/yum-3.4.3-505.fc22
I think this helps those users who read any of the docs out there
that say to 'yum install foo' at the cost of those people who need
some specific command line behavior from yum. The second group
is much better positioned to use yum-deprecated or know whats
going on than the first group.
kevin
2:50 a.m.
On Wed, 2015-04-01 at 13:40 -0600, Kevin Fenzi wrote:
There's some confusion around this, so I thought I would post to
try
and clear up things. In the event I am wrong on any of the below, please
do feel free to correct me. ;)
In the past the proposal was to have a yum-dnf package that provided
/usr/bin/yum, called dnf and conflicted with the yum package. I was
against that plan, but I think the one we settled on is worth doing.
It's somewhat of a middle ground between "yum is gone right now,
deal with it" and "you can keep using yum forever".
For f22 (and rawhide):
* dnf is installed by default. By that I mean it is in the 'core' group
in comps.
* dnf-yum is installed by default. By that I mean it is in the 'core'
group in comps next to dnf.
* yum is installed if something that depends on yum pulls it in or say
a user installs it manually.
* yum requires dnf-yum. So, if you install yum manually you will also
pull in dnf-yum (and the dnf plugin that handles history migrate).
* When you run 'yum' you get:
% sudo yum list foobar
Yum command has been deprecated, use dnf instead.
See 'man dnf' and 'man yum2dnf' for more information.
To transfer transaction metadata from yum to DNF, run 'dnf migrate'
Redirecting to '/usr/bin/dnf list foobar'
...then the ouput from dnf list foobar...
* If you wish to still use yum, the yum package provides now
a /usr/bin/yum-deprecated command that is the old yum
command renamed. It also has the notice message as above
on it.
* If you are using the yum python bindings directly, that will continue
to work if you have the yum package installed.
Note that this landed before Beta freeze, but there were some issues
with the initial package doing this. There is an update available:
https://admin.fedoraproject.org/updates/yum-3.4.3-505.fc22
I think this helps those users who read any of the docs out there
that say to 'yum install foo' at the cost of those people who need
some specific command line behavior from yum. The second group
is much better positioned to use yum-deprecated or know whats
going on than the first group.
kevin
--
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
Hi,
I want to ask on something not exactly to topic, but it's side of it. I
have a problem find command in dnf which is in yum.
When I'm using this command I get information which package contains
this library.
$ yum provides *libnetapi.so
but when I'm using dnf command
$ dnf repoquery --provides *libnetapi.so
Is there a way to find libraries and other files in dnf?
Thank you for answer.
3:02 a.m.
Hi,
On Thu, Apr 2, 2015 at 1:20 PM, Jiří Konečný <jkonecny(a)redhat.com> wrote:
On Wed, 2015-04-01 at 13:40 -0600, Kevin Fenzi wrote:
> There's some confusion around this, so I thought I would post to try
> and clear up things. In the event I am wrong on any of the below, please
> do feel free to correct me. ;)
>
> In the past the proposal was to have a yum-dnf package that provided
> /usr/bin/yum, called dnf and conflicted with the yum package. I was
> against that plan, but I think the one we settled on is worth doing.
> It's somewhat of a middle ground between "yum is gone right now,
> deal with it" and "you can keep using yum forever".
>
> For f22 (and rawhide):
>
> * dnf is installed by default. By that I mean it is in the 'core' group
> in comps.
>
> * dnf-yum is installed by default. By that I mean it is in the 'core'
> group in comps next to dnf.
>
> * yum is installed if something that depends on yum pulls it in or say
> a user installs it manually.
>
> * yum requires dnf-yum. So, if you install yum manually you will also
> pull in dnf-yum (and the dnf plugin that handles history migrate).
>
> * When you run 'yum' you get:
>
> % sudo yum list foobar
> Yum command has been deprecated, use dnf instead.
> See 'man dnf' and 'man yum2dnf' for more information.
> To transfer transaction metadata from yum to DNF, run 'dnf migrate'
> Redirecting to '/usr/bin/dnf list foobar'
>
> ...then the ouput from dnf list foobar...
>
> * If you wish to still use yum, the yum package provides now
> a /usr/bin/yum-deprecated command that is the old yum
> command renamed. It also has the notice message as above
> on it.
>
> * If you are using the yum python bindings directly, that will continue
> to work if you have the yum package installed.
>
> Note that this landed before Beta freeze, but there were some issues
> with the initial package doing this. There is an update available:
>
> https://admin.fedoraproject.org/updates/yum-3.4.3-505.fc22
>
> I think this helps those users who read any of the docs out there
> that say to 'yum install foo' at the cost of those people who need
> some specific command line behavior from yum. The second group
> is much better positioned to use yum-deprecated or know whats
> going on than the first group.
>
> kevin
> --
> 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
Hi,
I want to ask on something not exactly to topic, but it's side of it. I
have a problem find command in dnf which is in yum.
When I'm using this command I get information which package contains
this library.
$ yum provides *libnetapi.so
but when I'm using dnf command
$ dnf repoquery --provides *libnetapi.so
Is there a way to find libraries and other files in dnf?
You can use
$ dnf provides *libnetapi.so
Regards,
Parag.
4:31 a.m.
On Thu, 2015-04-02 at 13:32 +0530, Parag Nemade wrote:
Hi,
On Thu, Apr 2, 2015 at 1:20 PM, Jiří Konečný <jkonecny(a)redhat.com> wrote:
> On Wed, 2015-04-01 at 13:40 -0600, Kevin Fenzi wrote:
>> There's some confusion around this, so I thought I would post to try
>> and clear up things. In the event I am wrong on any of the below, please
>> do feel free to correct me. ;)
>>
>> In the past the proposal was to have a yum-dnf package that provided
>> /usr/bin/yum, called dnf and conflicted with the yum package. I was
>> against that plan, but I think the one we settled on is worth doing.
>> It's somewhat of a middle ground between "yum is gone right now,
>> deal with it" and "you can keep using yum forever".
>>
>> For f22 (and rawhide):
>>
>> * dnf is installed by default. By that I mean it is in the 'core' group
>> in comps.
>>
>> * dnf-yum is installed by default. By that I mean it is in the 'core'
>> group in comps next to dnf.
>>
>> * yum is installed if something that depends on yum pulls it in or say
>> a user installs it manually.
>>
>> * yum requires dnf-yum. So, if you install yum manually you will also
>> pull in dnf-yum (and the dnf plugin that handles history migrate).
>>
>> * When you run 'yum' you get:
>>
>> % sudo yum list foobar
>> Yum command has been deprecated, use dnf instead.
>> See 'man dnf' and 'man yum2dnf' for more information.
>> To transfer transaction metadata from yum to DNF, run 'dnf migrate'
>> Redirecting to '/usr/bin/dnf list foobar'
>>
>> ...then the ouput from dnf list foobar...
>>
>> * If you wish to still use yum, the yum package provides now
>> a /usr/bin/yum-deprecated command that is the old yum
>> command renamed. It also has the notice message as above
>> on it.
>>
>> * If you are using the yum python bindings directly, that will continue
>> to work if you have the yum package installed.
>>
>> Note that this landed before Beta freeze, but there were some issues
>> with the initial package doing this. There is an update available:
>>
>> https://admin.fedoraproject.org/updates/yum-3.4.3-505.fc22
>>
>> I think this helps those users who read any of the docs out there
>> that say to 'yum install foo' at the cost of those people who need
>> some specific command line behavior from yum. The second group
>> is much better positioned to use yum-deprecated or know whats
>> going on than the first group.
>>
>> kevin
>> --
>> 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
>
> Hi,
>
> I want to ask on something not exactly to topic, but it's side of it. I
> have a problem find command in dnf which is in yum.
>
> When I'm using this command I get information which package contains
> this library.
> $ yum provides *libnetapi.so
>
> but when I'm using dnf command
> $ dnf repoquery --provides *libnetapi.so
>
>
> Is there a way to find libraries and other files in dnf?
You can use
$ dnf provides *libnetapi.so
Regards,
Parag.
Ohh nice I must missed this.
Thank you
7:23 a.m.
On Thu, 02 Apr 2015 09:50:05 +0200, Jiří Konečný wrote:
When I'm using this command I get information which package
contains
this library.
$ yum provides *libnetapi.so
but when I'm using dnf command
$ dnf repoquery --provides *libnetapi.so
Besides other replies to make it clear: There is a confusion between 'provides'
and 'whatprovides'. 'dnf repoquery' behaves the same like
'repoquery' (from
yum-utils) and like rpm:
rpm:
--whatprovides query/verify the package(s) which provide
--provides list capabilities that this package provides
repoquery:
--provides list capabilities this package provides
--whatprovides query what package(s) provide a capability
dnf repoquery provides foo: (?? dnf repoquery --help does not work)
--whatprovides REQ show only results there provides REQ
--provides Display capabilities provided by the package.
vs.
dnf:
provides Find what package provides the given value
yum:
provides Find what package provides the given value
So: dnf/yum provides <=> rpm/repoqiery/dnf-repoquery --whatprovides
dnf/yum N/A <=> rpm/repoqiery/dnf-repoquery --provides
rpm/repoquery just do not support wildcards so one has to type:
repoquery --whatprovides 'libnetapi.so.0()(64bit)'
dnf repoquery --whatprovides 'libnetapi.so.0()(64bit)'
Jan
7:27 a.m.
On Thu, 2015-04-02 at 14:23 +0200, Jan Kratochvil wrote:
On Thu, 02 Apr 2015 09:50:05 +0200, Jiří Konečný wrote:
rpm/repoquery just do not support wildcards so one has to type:
repoquery --whatprovides 'libnetapi.so.0()(64bit)'
dnf repoquery --whatprovides 'libnetapi.so.0()(64bit)'
That's not entirely true:
$ repoquery --whatprovides 'libnetapi.so.0*64*'
samba-libs-2:4.1.17-1.fc21.x86_64
samba-libs-2:4.1.12-5.fc21.x86_64
DNF however:
$ dnf repoquery --whatprovides 'libnetapi.so.0*64*'
Using metadata from Thu Apr 2 14:26:05 2015
--
Mathieu
8:10 a.m.
On Thu, 2 Apr 2015 14:23:45 +0200
Jan Kratochvil <jan.kratochvil(a)redhat.com> wrote:
rpm/repoquery just do not support wildcards so one has to type:
repoquery --whatprovides 'libnetapi.so.0()(64bit)'
dnf repoquery --whatprovides 'libnetapi.so.0()(64bit)'
Jan
Is this a different scenario?
~$ repoquery --whatprovides libnetapi*
samba-client-libs-2:4.2.0-2.fc22.x86_64
samba-client-libs-2:4.2.0-2.fc22.x86_64
dnf repoquery did require the full text as your example above.
dnf-0.6.5-1.fc22.noarch
yum-utils-1.1.31-27.fc22.noarch
___
Regards
Frank Murphy
4:22 a.m.
From: "Kevin Fenzi" <kevin(a)scrye.com>
There's some confusion around this, so I thought I would post to try
and clear up things. In the event I am wrong on any of the below, please
do feel free to correct me. ;)
In the past the proposal was to have a yum-dnf package that provided
/usr/bin/yum, called dnf and conflicted with the yum package. I was
against that plan, but I think the one we settled on is worth doing.
It's somewhat of a middle ground between "yum is gone right now,
deal with it" and "you can keep using yum forever".
For f22 (and rawhide):
* dnf is installed by default. By that I mean it is in the 'core' group
in comps.
* dnf-yum is installed by default. By that I mean it is in the 'core'
group in comps next to dnf.
* yum is installed if something that depends on yum pulls it in or say
a user installs it manually.
* yum requires dnf-yum. So, if you install yum manually you will also
pull in dnf-yum (and the dnf plugin that handles history migrate).
* When you run 'yum' you get:
% sudo yum list foobar
Yum command has been deprecated, use dnf instead.
See 'man dnf' and 'man yum2dnf' for more information.
To transfer transaction metadata from yum to DNF, run 'dnf migrate'
Redirecting to '/usr/bin/dnf list foobar'
...then the ouput from dnf list foobar...
* If you wish to still use yum, the yum package provides now
a /usr/bin/yum-deprecated command that is the old yum
command renamed. It also has the notice message as above
on it.
* If you are using the yum python bindings directly, that will continue
to work if you have the yum package installed.
Note that this landed before Beta freeze, but there were some issues
with the initial package doing this. There is an update available:
https://admin.fedoraproject.org/updates/yum-3.4.3-505.fc22
I think this helps those users who read any of the docs out there
that say to 'yum install foo' at the cost of those people who need
some specific command line behavior from yum. The second group
is much better positioned to use yum-deprecated or know whats
going on than the first group.
Exactly, thanks for writing this, Kevin.
All man pages / warnings were updated according to these changes so there
should be no harm / confusion during yum to DNF transition.
BTW new migration plugin [1] was created to import transactions, installed
packages and group metadata from yum to DNF.
[1] http://dnf-plugins-extras.readthedocs.org/en/latest/migrate.html
DNF team
1:38 p.m.
Hi
On Wed, Apr 1, 2015 at 3:40 PM, Kevin Fenzi wrote:
* When you run 'yum' you get:
% sudo yum list foobar
Yum command has been deprecated, use dnf instead.
See 'man dnf' and 'man yum2dnf' for more information.
To transfer transaction metadata from yum to DNF, run 'dnf migrate'
Redirecting to '/usr/bin/dnf list foobar'
All of this seems a bit rushed considering the schedule.
I have to say I agree with some of the comments in
https://fedorahosted.org/fesco/ticket/1312
including Dennis Gilmore and Matthew Miller. While I am glad dnf-yum is
now intended to be there by default and there is a better transition, I
would prefer if using yum didn't result in this pretty large message
upfront. The small number of differences between yum and dnf doesn't seem
to warrant this needless churn since massive internal changes and even some
command line changes have occurred between revisions of yum itself.
It would be much better if we can just stick to yum as the name of the
command esp now that the classic yum command itself has been renamed to
yum-deprecated resulting in no conflicts.
Rahul
7:34 a.m.
On Wed, Apr 1, 2015 at 3:40 PM, Kevin Fenzi <kevin(a)scrye.com> wrote:
There's some confusion around this, so I thought I would post to
try
and clear up things. In the event I am wrong on any of the below, please
do feel free to correct me. ;)
In the past the proposal was to have a yum-dnf package that provided
/usr/bin/yum, called dnf and conflicted with the yum package. I was
against that plan, but I think the one we settled on is worth doing.
It's somewhat of a middle ground between "yum is gone right now,
deal with it" and "you can keep using yum forever".
I'm reading it. I'm afraid it's unnecessarily confusing, and there's
already a workable approach with "/etc/alternatives" used for Java and
sendmail equivalents. Why re-invent the wheel?
For f22 (and rawhide):
* dnf is installed by default. By that I mean it is in the 'core' group
in comps.
* dnf-yum is installed by default. By that I mean it is in the 'core'
group in comps next to dnf.
As opposed to providing the binaries or wrappers in an alternative
location, adding /etc/alternatives hooks to link dnf-yum components to
/usr/bin/yum, and putting in .spec staqnzs that says "Provides: yum"
* yum is installed if something that depends on yum pulls it in or
say
a user installs it manually.
* yum requires dnf-yum. So, if you install yum manually you will also
pull in dnf-yum (and the dnf plugin that handles history migrate).
As opposed to alternating the binary installation location and using
/etc/alternatives to link it to /usr/bin/yum.
This approach is old and effective for Java, for /usr/sbin/sendmail,
and for numerous other tools. Why would you want to reinvent the wheel
and prevent people from having either as needed?
* When you run 'yum' you get:
% sudo yum list foobar
Yum command has been deprecated, use dnf instead.
See 'man dnf' and 'man yum2dnf' for more information.
To transfer transaction metadata from yum to DNF, run 'dnf migrate'
Redirecting to '/usr/bin/dnf list foobar'
...then the ouput from dnf list foobar...
* If you wish to still use yum, the yum package provides now
a /usr/bin/yum-deprecated command that is the old yum
command renamed. It also has the notice message as above
on it.
See above.
* If you are using the yum python bindings directly, that will
continue
to work if you have the yum package installed.
Note that this landed before Beta freeze, but there were some issues
with the initial package doing this. There is an update available:
https://admin.fedoraproject.org/updates/yum-3.4.3-505.fc22
I think this helps those users who read any of the docs out there
that say to 'yum install foo' at the cost of those people who need
some specific command line behavior from yum. The second group
is much better positioned to use yum-deprecated or know whats
going on than the first group.
kevin
I think that, if you're suggesting the approach, you're trying to
re-invent the same wheel that multiple KDE and Python and Java and
SMTP server have been cycling around on for a long, long time, and
it's a serious tactical error. Don't try to outsmart the user and
decide that the packages must forcibly conflict. Let them have both,
and set the default to something sane.
7:53 a.m.
On 3. 4. 2015 at 08:34:16, Nico Kadel-Garcia wrote:
On Wed, Apr 1, 2015 at 3:40 PM, Kevin Fenzi <kevin(a)scrye.com>
wrote:
> There's some confusion around this, so I thought I would post to try
> and clear up things. In the event I am wrong on any of the below, please
> do feel free to correct me. ;)
>
> In the past the proposal was to have a yum-dnf package that provided
> /usr/bin/yum, called dnf and conflicted with the yum package. I was
> against that plan, but I think the one we settled on is worth doing.
> It's somewhat of a middle ground between "yum is gone right now,
> deal with it" and "you can keep using yum forever".
I'm reading it. I'm afraid it's unnecessarily confusing, and there's
already a workable approach with "/etc/alternatives" used for Java and
sendmail equivalents. Why re-invent the wheel?
> For f22 (and rawhide):
>
> * dnf is installed by default. By that I mean it is in the 'core' group
>
> in comps.
>
> * dnf-yum is installed by default. By that I mean it is in the 'core'
>
> group in comps next to dnf.
As opposed to providing the binaries or wrappers in an alternative
location, adding /etc/alternatives hooks to link dnf-yum components to
/usr/bin/yum, and putting in .spec staqnzs that says "Provides: yum"
> * yum is installed if something that depends on yum pulls it in or say
>
> a user installs it manually.
>
> * yum requires dnf-yum. So, if you install yum manually you will also
>
> pull in dnf-yum (and the dnf plugin that handles history migrate).
As opposed to alternating the binary installation location and using
/etc/alternatives to link it to /usr/bin/yum.
This approach is old and effective for Java, for /usr/sbin/sendmail,
and for numerous other tools. Why would you want to reinvent the wheel
and prevent people from having either as needed?
> * When you run 'yum' you get:
>
> % sudo yum list foobar
> Yum command has been deprecated, use dnf instead.
> See 'man dnf' and 'man yum2dnf' for more information.
> To transfer transaction metadata from yum to DNF, run 'dnf migrate'
> Redirecting to '/usr/bin/dnf list foobar'
>
> ...then the ouput from dnf list foobar...
>
> * If you wish to still use yum, the yum package provides now
>
> a /usr/bin/yum-deprecated command that is the old yum
> command renamed. It also has the notice message as above
> on it.
See above.
> * If you are using the yum python bindings directly, that will continue
>
> to work if you have the yum package installed.
>
> Note that this landed before Beta freeze, but there were some issues
> with the initial package doing this. There is an update available:
>
> https://admin.fedoraproject.org/updates/yum-3.4.3-505.fc22
>
> I think this helps those users who read any of the docs out there
> that say to 'yum install foo' at the cost of those people who need
> some specific command line behavior from yum. The second group
> is much better positioned to use yum-deprecated or know whats
> going on than the first group.
>
> kevin
I think that, if you're suggesting the approach, you're trying to
re-invent the same wheel that multiple KDE and Python and Java and
SMTP server have been cycling around on for a long, long time, and
it's a serious tactical error. Don't try to outsmart the user and
decide that the packages must forcibly conflict. Let them have both,
and set the default to something sane.
I think you might have misunderstood what's happening. We don't want to offer
dnf as an alternative to yum. Dnf is its successor. Yum is deprecated by dnf
in F22 and is very likely going to be removed in one of the next releases.
That's why we want to migrate users to dnf but at the same time we want to
give them a possibility to stay a little bit longer on yum if absolutely
necessary.
Thanks for understanding
Jan
8:22 a.m.
2015-04-07 9:53 GMT-03:00 Jan Zelený <jzeleny(a)redhat.com>:
[...]
I think you might have misunderstood what's happening. We
don't want to offer
Hopefully I did not :)
dnf as an alternative to yum. Dnf is its successor. Yum is deprecated
by dnf
in F22 and is very likely going to be removed in one of the next releases.
For releases I expect it to be functional. I use rawhide for several years
already, so I am used to stuff breaking.
The problem is that fedora-review and/or mock were broken for more
than two months, see https://bugzilla.redhat.com/show_bug.cgi?id=1208912
so I was using -o--yum.
I had also switched back to yum in rawhide due to --skip-broken, and
in a few updates not even needing it (I would first see what is broken,
and if not something "vital", use --skip-broken), while dnf would just fail
with cryptic messages. I can keep up if kde or gnome is broken, or
some other stuff that does not prevent boot and a functional system.
That's why we want to migrate users to dnf but at the same time
we want to
give them a possibility to stay a little bit longer on yum if absolutely
necessary.
Thanks for understanding
Jan
Thanks,
Paulo
8:26 a.m.
Am 07.04.2015 um 15:22 schrieb "Paulo =?iso-8859-1?b?Q+lzYXI=?= Pereira
de Andrade
=?us-ascii?q?=3Cpaulo=2Ecesar=2Epereira=2Ede=2Eandrade=40gmail=2E?=
=?us-ascii?q?com=3E?=":
2015-04-07 9:53 GMT-03:00 Jan Zelený <jzeleny(a)redhat.com>:
[...]
> I think you might have misunderstood what's happening. We don't want to
offer
Hopefully I did not :)
the response did go to Nico Kadel-Garcia which proposed the alternatives
system
> dnf as an alternative to yum. Dnf is its successor. Yum is
deprecated by dnf
> in F22 and is very likely going to be removed in one of the next releases.
For releases I expect it to be functional. I use rawhide for several years
already, so I am used to stuff breaking.
The problem is that fedora-review and/or mock were broken for more
than two months, see https://bugzilla.redhat.com/show_bug.cgi?id=1208912
so I was using -o--yum
that are bugs which needs to be solved and not worked around by
introduce alternatives which are *not* suitebale for proposed *replacements*
8:38 a.m.
On Tue, Apr 07, 2015 at 10:22:25 -0300,
Paulo César Pereira de Andrade <paulo.cesar.pereira.de.andrade(a)gmail.com> wrote:
I had also switched back to yum in rawhide due to --skip-broken, and
in a few updates not even needing it (I would first see what is broken,
and if not something "vital", use --skip-broken), while dnf would just fail
with cryptic messages. I can keep up if kde or gnome is broken, or
some other stuff that does not prevent boot and a functional system.
dnf really does need --skip-broken like support if it is to replace yum.
yum can be a lot faster than the needed work around to get dnf to work
equivalently. I am considering going back to yum in rawhide rather than
continuig to test dnf in rawhide because of this issue.
10:07 a.m.
On Tue, 7 Apr 2015 08:38:57 -0500
Bruno Wolff III <bruno(a)wolff.to> wrote:
On Tue, Apr 07, 2015 at 10:22:25 -0300,
Paulo César Pereira de Andrade
<paulo.cesar.pereira.de.andrade(a)gmail.com> wrote:
>
> I had also switched back to yum in rawhide due to --skip-broken,
> and
>in a few updates not even needing it (I would first see what is
>broken, and if not something "vital", use --skip-broken), while dnf
>would just fail with cryptic messages. I can keep up if kde or gnome
>is broken, or some other stuff that does not prevent boot and a
>functional system.
dnf really does need --skip-broken like support if it is to replace
yum. yum can be a lot faster than the needed work around to get dnf
to work equivalently. I am considering going back to yum in rawhide
rather than continuig to test dnf in rawhide because of this issue.
dnf's default behavior is like yum with --skip-broken already.
If thats not working and you need to find out more, add '--best' to see
things without 'skip-broken'.
If that still doesn't work, please file a bug. ;)
kevin
10:51 a.m.
On Tue, Apr 07, 2015 at 09:07:08 -0600,
Kevin Fenzi <kevin(a)scrye.com> wrote:
dnf's default behavior is like yum with --skip-broken already.
Not when installing packages.
If thats not working and you need to find out more, add '--best' to see
things without 'skip-broken'.
My understanding is that --best can erase stuff (outside of obsoletes)
and I don't want to do that in scripts.
If that still doesn't work, please file a bug. ;)
I have already filed some bugs and RFEs since dnf replaced yum in rawhide,
including about needing --skip-broken like functionallity for installs.
11:09 a.m.
On Tue, 7 Apr 2015 at 17:54 Bruno Wolff III <bruno(a)wolff.to> wrote:
On Tue, Apr 07, 2015 at 09:07:08 -0600,
Kevin Fenzi <kevin(a)scrye.com> wrote:
>
>dnf's default behavior is like yum with --skip-broken already.
Not when installing packages.
>
>If thats not working and you need to find out more, add '--best' to see
>things without 'skip-broken'.
My understanding is that --best can erase stuff (outside of obsoletes)
and I don't want to do that in scripts.
afaik, --best don't erase stuff, you need --allowerasing for that
--bestTry the best available package versions in transactions. Specifically
during dnf upgrade, which by default skips over updates that can not be
installed for dependency reasons, the switch forces DNF to only consider
the latest packages and possibly fail giving a reason why the latest
version can not be installed.
Tim
11:33 a.m.
On Tue, Apr 07, 2015 at 16:09:46 +0000,
Tim Lauridsen <tim.lauridsen(a)gmail.com> wrote:
afaik, --best don't erase stuff, you need --allowerasing for that
--bestTry the best available package versions in transactions. Specifically
during dnf upgrade, which by default skips over updates that can not be
installed for dependency reasons, the switch forces DNF to only consider
the latest packages and possibly fail giving a reason why the latest
version can not be installed.
Thanks for the explanation.
It looks like --best would only affect updates in rare cases.
11:34 a.m.
On 04/07/2015 06:09 PM, Tim Lauridsen wrote:
On Tue, 7 Apr 2015 at 17:54 Bruno Wolff III <bruno(a)wolff.to
<mailto:bruno@wolff.to>> wrote:
On Tue, Apr 07, 2015 at 09:07:08 -0600,
Kevin Fenzi <kevin(a)scrye.com <mailto:kevin@scrye.com>> wrote:
>
>dnf's default behavior is like yum with --skip-broken already.
Not when installing packages.
>
>If thats not working and you need to find out more, add '--best'
to see
>things without 'skip-broken'.
My understanding is that --best can erase stuff (outside of obsoletes)
and I don't want to do that in scripts.
afaik, --best don't erase stuff, you need --allowerasing for that
--best
Try the best available package versions in transactions.
Specifically during dnf upgrade, which by default skips over updates
that can not be installed for dependency reasons, the switch forces
DNF to only consider the latest packages and possibly fail giving a
reason why the latest version can not be installed.
Pardon, folks - But haven't we been told dnf was supposed to be yum
compatible?
I have to admit, I can't deny finding this kind of discussion to be very
discurbing. They confirm my gut feelings about dnf is being not ready
prime time and all recent decisions to make it default in mock and yum
to be premature.
1:32 a.m.
On 7. 4. 2015 at 18:34:49, Ralf Corsepius wrote:
On 04/07/2015 06:09 PM, Tim Lauridsen wrote:
> On Tue, 7 Apr 2015 at 17:54 Bruno Wolff III <bruno(a)wolff.to
>
> <mailto:bruno@wolff.to>> wrote:
> On Tue, Apr 07, 2015 at 09:07:08 -0600,
>
> Kevin Fenzi <kevin(a)scrye.com <mailto:kevin@scrye.com>> wrote:
> >dnf's default behavior is like yum with --skip-broken already.
>
> Not when installing packages.
>
> >If thats not working and you need to find out more, add '--best'
>
> to see
>
> >things without 'skip-broken'.
>
> My understanding is that --best can erase stuff (outside of obsoletes)
> and I don't want to do that in scripts.
>
> afaik, --best don't erase stuff, you need --allowerasing for that
>
> --best
>
> Try the best available package versions in transactions.
> Specifically during dnf upgrade, which by default skips over updates
> that can not be installed for dependency reasons, the switch forces
> DNF to only consider the latest packages and possibly fail giving a
> reason why the latest version can not be installed.
Pardon, folks - But haven't we been told dnf was supposed to be yum
compatible?
I'm afraid not. From the very beginning, we were sending a clear message that
we will be as compatible as possible in terms of CLI but we never wanted to
have just another yum. If that was the case, we wouldn't call the project
differently.
I have to admit, I can't deny finding this kind of discussion to
be very
discurbing. They confirm my gut feelings about dnf is being not ready
prime time and all recent decisions to make it default in mock and yum
to be premature.
That's your opinion and I will not argue with you about it. Yum is still in
Fedora for people who share your opinion. If you have something specific that
you miss in dnf, feel free to open a bug and start a discussion with us. We
are very open to new ideas which you guys support with valid use cases, even
though I admit that some cases need to be backed by a number of requests, as
we want to implement only those features that have real impact and that matter
to a large number of our users.
Thanks
Jan
8:24 a.m.
Jan Zelený <jzeleny(a)redhat.com> wrote:
On 7. 4. 2015 at 18:34:49, Ralf Corsepius wrote:
> Pardon, folks - But haven't we been told dnf was supposed to be yum
> compatible?
I'm afraid not. From the very beginning, we were sending a clear message that
we will be as compatible as possible in terms of CLI but we never wanted to
have just another yum. If that was the case, we wouldn't call the project
differently.
Your definition of "possible" seems to be different from mine. To me
"possible" means that it doesn't require doing something impossible
such as solving the halting problem. As I don't know what you consider
possible I can't tell how compatible Yum and DNF are really supposed to
be.
If you mean that DNF will duplicate those parts of Yum's CLI that are
reasonably straightforward to implement on top of DNF's internal
architecture, then it would be better to say that.
If you mean that DNF will duplicate the most commonly used of Yum's
features, then please say that.
If you mean that whenever DNF happens to have a feature that works
similarly to one of Yum's features it will have the same name so that
users will recognize it, then please say that.
Björn Persson
7:52 a.m.
On 9. 4. 2015 at 15:24:53, Björn Persson wrote:
Jan Zelený <jzeleny(a)redhat.com> wrote:
> On 7. 4. 2015 at 18:34:49, Ralf Corsepius wrote:
> > Pardon, folks - But haven't we been told dnf was supposed to be yum
> > compatible?
>
> I'm afraid not. From the very beginning, we were sending a clear message
> that we will be as compatible as possible in terms of CLI but we never
> wanted to have just another yum. If that was the case, we wouldn't call
> the project differently.
Your definition of "possible" seems to be different from mine. To me
"possible" means that it doesn't require doing something impossible
such as solving the halting problem. As I don't know what you consider
possible I can't tell how compatible Yum and DNF are really supposed to
be.
If you mean that DNF will duplicate those parts of Yum's CLI that are
reasonably straightforward to implement on top of DNF's internal
architecture, then it would be better to say that.
Yes ... mostly
As it turns out, many of the features are implemented on more places in yum
and some of the features are hardly used. Those might not get in.
If you mean that DNF will duplicate the most commonly used of
Yum's
features, then please say that.
Yes ... mostly
Let's not hang upon features and say the most common use cases will be
covered.
If you mean that whenever DNF happens to have a feature that works
similarly to one of Yum's features it will have the same name so that
users will recognize it, then please say that.
Yes ... mostly
Not always. Many of yum features grew organically and in time they got very
different from their original purpose so it might make sense to rename them.
Also some of dnf's features cover functionality of more than one yum feature
and we don't want to make aliases that are not necessary.
Thanks
Jan
10:01 a.m.
On 04/08/2015 02:32 AM, Jan Zelený wrote
I'm afraid not. From the very beginning, we were sending a clear
message that
we will be as compatible as possible in terms of CLI but we never wanted to
have just another yum. If that was the case, we wouldn't call the project
differently.
I am concerned that the yum-to-dnf transition is confusing, because of
this mixed message. On one hand, they are just two package management
tools: on a high level, they do a simple, well defined job of updating
your system to the latest version of available packages. In an ideal
world it just wouldn't matter which one you use, and from that point of
view the name change is superfluous: all you need to do is 'yum update',
and calling it 'dnf update' is just a tiny annoyance that is not
bothersome enough to be worth bothering about.
We are not living in an ideal world, however, and the updating problem
is complex enough so that yum ecosystem is not handling it well. You are
making an argument that dnf reimplemented this ecosystem in a
qualitatively different, more correct way, that is so different that it
merits a clean break, justifying the project name change. I am fine with
that, but this leads to confusion when there are observable changes in
behavior. The implication is that dnf is better and more correct, but on
the other hand it's clear that dnf is still in development and exhibits
faults. So, now we have a problem: if dnf behaves differently from yum,
is it an improvement or a regression? We don't know, and it's not clear
to me how to tell; every divergence is a potential bug in dnf, and
therefore should be reported as such.
I would venture a comment that it was a mistake to declare dnf a
separate project, because it leads to a different approach to such
differences. If it was an evolutionary change in yum, it would be
natural to expect it to behave in a compatible way, and consequently
detect and explain in more detail the divergent behavior. By declaring a
clean break, you are basically saying that there is no need to explain
the diffs, but the flip side of it is that unless I can clearly
understand why the difference is for the better, I must suspect this to
be a regression and report it.
As a result, dnf will have a huge bug load that is hard to work with
because it depends on a specific state of the repositories at that
specific moment in time. Do you have a capability to investigate such
problems? Here's a specific one, a firefox update from this morning that
shows up in yum but not in dnf. I will submit it to bugzilla, just to
see where we go with that.
# dnf update firefox
Using metadata from Fri Apr 3 03:24:08 2015
Dependencies resolved.
Nothing to do.
# yum update firefox
Loaded plugins: auto-update-debuginfo, langpacks
Resolving Dependencies
--> Running transaction check
---> Package firefox.x86_64 0:37.0-2.fc21 will be updated
---> Package firefox.x86_64 0:37.0.1-1.fc21 will be an update
--> Finished Dependency Resolution
# dnf info firefox
Using metadata from Fri Apr 3 03:24:08 2015
Installed Packages
Name : firefox
Arch : x86_64
Epoch : 0
Version : 37.0
Release : 2.fc21
...
# yum info firefox
Loaded plugins: auto-update-debuginfo, langpacks
Installed Packages
Name : firefox
Arch : x86_64
Version : 37.0
Release : 2.fc21
...
Available Packages
Name : firefox
Arch : x86_64
Version : 37.0.1
Release : 1.fc21
Size : 69 M
Repo : updates/21/x86_64
...
10:13 a.m.
On 04/09/2015 11:05 AM, Michal Luscon wrote:
On 04/09/2015 05:01 PM, Przemek Klosowski wrote:
> Using metadata from Fri Apr 3 03:24:08 2015
^^^ the key part of DNF output
Well, OK, but when I just re-run 'dnf
update' it updates firefox now:
Using metadata from Fri Apr 3 03:24:08 2015
^^^ same timestamp as before, but
different result
...
Dependencies resolved.
...
firefox x86_64 37.0.1-1.fc21
updates 69 M
This is a definition of craziness: you do the same thing twice and
expect a different return. In the end, I can't say that it doesn't work
but I have an uneasy feeling that I do not understand how an essential
part of my system works.
1:23 p.m.
----- Original Message -----
From: "Przemek Klosowski"
<przemek.klosowski(a)nist.gov>
To: devel(a)lists.fedoraproject.org
Sent: Thursday, April 9, 2015 5:13:49 PM
Subject: Re: dnf replacing yum and dnf-yum
On 04/09/2015 11:05 AM, Michal Luscon wrote:
> On 04/09/2015 05:01 PM, Przemek Klosowski wrote:
> > Using metadata from Fri Apr 3 03:24:08 2015
>
> ^^^ the key part of DNF output
Well, OK, but when I just re-run 'dnf update' it updates
firefox now:
> Using metadata from Fri Apr 3 03:24:08 2015
> ^^^ same timestamp as before, but different result
> ...
> Dependencies resolved.
> ...
> firefox x86_64 37.0.1-1.fc21 updates 69 M
This is a definition of craziness: you do the same thing twice and
expect a
different return. In the end, I can't say that it doesn't work but I have an
uneasy feeling that I do not understand how an essential part of my system
works.
The reason is that even if metadata of the "updates" repository have been
refreshed, there is probably another repository with matadata from Fri Apr 3 03:24:08 2015
(it has probably longer expiration period). So, yes, I agree that this is confusing.
Do you have a better idea than printing the timestamp for each repository?
--
Radek Holý
Associate Software Engineer
Software Management Team
Red Hat Czech
1:44 a.m.
On 9.4.2015 20:23, Radek Holy wrote:
----- Original Message -----
> From: "Przemek Klosowski" <przemek.klosowski(a)nist.gov>
> To: devel(a)lists.fedoraproject.org
> Sent: Thursday, April 9, 2015 5:13:49 PM
> Subject: Re: dnf replacing yum and dnf-yum
> On 04/09/2015 11:05 AM, Michal Luscon wrote:
>> On 04/09/2015 05:01 PM, Przemek Klosowski wrote:
>
>>> Using metadata from Fri Apr 3 03:24:08 2015
>>
>
>> ^^^ the key part of DNF output
>
> Well, OK, but when I just re-run 'dnf update' it updates firefox now:
>> Using metadata from Fri Apr 3 03:24:08 2015
>
>> ^^^ same timestamp as before, but different result
>
>> ...
>
>> Dependencies resolved.
>
>> ...
>
>> firefox x86_64 37.0.1-1.fc21 updates 69 M
>
> This is a definition of craziness: you do the same thing twice and expect a
> different return. In the end, I can't say that it doesn't work but I have an
> uneasy feeling that I do not understand how an essential part of my system
> works.
The reason is that even if metadata of the "updates" repository have been
refreshed, there is probably another repository with matadata from Fri Apr 3 03:24:08 2015
(it has probably longer expiration period). So, yes, I agree that this is confusing.
Do you have a better idea than printing the timestamp for each repository?
Maybe it could print oldest + newest timestamp, possibly with repo names?
I mean something like:
"Metadata: Oldest repo fedora-release (Fri Apr 3 03:24:08 2015, 4 days old),
newest repo fedora-updates-testing (Fri Apr 10 00:00:00 2015, 10 minutes
old)." or something like that.
--
Petr Spacek @ Red Hat
4:50 a.m.
----- Original Message -----
From: "Petr Spacek" <pspacek(a)redhat.com>
To: devel(a)lists.fedoraproject.org
Sent: Friday, April 10, 2015 8:44:03 AM
Subject: Re: dnf replacing yum and dnf-yum
On 9.4.2015 20:23, Radek Holy wrote:
> ----- Original Message -----
>
>> From: "Przemek Klosowski" <przemek.klosowski(a)nist.gov>
>> To: devel(a)lists.fedoraproject.org
>> Sent: Thursday, April 9, 2015 5:13:49 PM
>> Subject: Re: dnf replacing yum and dnf-yum
>
>> On 04/09/2015 11:05 AM, Michal Luscon wrote:
>
>>> On 04/09/2015 05:01 PM, Przemek Klosowski wrote:
>>
>
>>>> Using metadata from Fri Apr 3 03:24:08 2015
>>>
>>
>
>>> ^^^ the key part of DNF output
>>
>
>> Well, OK, but when I just re-run 'dnf update' it updates firefox now:
>
>>> Using metadata from Fri Apr 3 03:24:08 2015
>>
>>> ^^^ same timestamp as before, but different result
>>
>>> ...
>>
>>> Dependencies resolved.
>>
>>> ...
>>
>>> firefox x86_64 37.0.1-1.fc21 updates 69 M
>>
>
>> This is a definition of craziness: you do the same thing twice and expect
>> a
>> different return. In the end, I can't say that it doesn't work but I
have
>> an
>> uneasy feeling that I do not understand how an essential part of my system
>> works.
>
> The reason is that even if metadata of the "updates" repository have been
> refreshed, there is probably another repository with matadata from Fri Apr
> 3 03:24:08 2015 (it has probably longer expiration period). So, yes, I
> agree that this is confusing.
>
> Do you have a better idea than printing the timestamp for each repository?
Maybe it could print oldest + newest timestamp, possibly with repo names?
I mean something like:
"Metadata: Oldest repo fedora-release (Fri Apr 3 03:24:08 2015, 4 days old),
newest repo fedora-updates-testing (Fri Apr 10 00:00:00 2015, 10 minutes
old)." or something like that.
I doubt that it can solve every confusion related to this problem but if you, DNF users,
find it sufficient, I have no problem with this improvement. My opinion is that the more
text we print the less users will read it...
So, if anyone find one of these ideas (or any other) useful, please, file an RFE.
Thank you in advance
--
Radek Holý
Associate Software Engineer
Software Management Team
Red Hat Czech
11:13 a.m.
Am 09.04.2015 um 17:01 schrieb Przemek Klosowski:
On 04/08/2015 02:32 AM, Jan Zelený wrote
> I'm afraid not. From the very beginning, we were sending a clear message that
> we will be as compatible as possible in terms of CLI but we never wanted to
> have just another yum. If that was the case, we wouldn't call the project
> differently.
I am concerned that the yum-to-dnf transition is confusing, because of
this mixed message. On one hand, they are just two package management
tools: on a high level, they do a simple, well defined job of updating
your system to the latest version of available packages. In an ideal
world it just wouldn't matter which one you use, and from that point of
view the name change is superfluous: all you need to do is 'yum update',
and calling it 'dnf update' is just a tiny annoyance that is not
bothersome enough to be worth bothering about
nobody cares about the annoyance
while the original promise was "dnf will be a fork of current yum and
later renamed back to yum" this no longer bothers anybody and it was
decided that user confusion is no problem as long as developer egos are fine
1:36 p.m.
----- Original Message -----
From: "Przemek Klosowski"
<przemek.klosowski(a)nist.gov>
To: devel(a)lists.fedoraproject.org
Sent: Thursday, April 9, 2015 5:01:19 PM
Subject: Re: dnf replacing yum and dnf-yum
On 04/08/2015 02:32 AM, Jan Zelený wrote
> I'm afraid not. From the very beginning, we were sending a
clear message
> that
> we will be as compatible as possible in terms of CLI but we never wanted to
> have just another yum. If that was the case, we wouldn't call the project
> differently.
I am concerned that the yum-to-dnf transition is confusing, because
of this
mixed message. On one hand, they are just two package management tools: on a
high level, they do a simple, well defined job of updating your system to
the latest version of available packages. In an ideal world it just wouldn't
matter which one you use, and from that point of view the name change is
superfluous: all you need to do is 'yum update', and calling it 'dnf
update'
is just a tiny annoyance that is not bothersome enough to be worth bothering
about.
We are not living in an ideal world, however, and the updating
problem is
complex enough so that yum ecosystem is not handling it well. You are making
an argument that dnf reimplemented this ecosystem in a qualitatively
different, more correct way, that is so different that it merits a clean
break, justifying the project name change. I am fine with that, but this
leads to confusion when there are observable changes in behavior. The
implication is that dnf is better and more correct, but on the other hand
it's clear that dnf is still in development and exhibits faults. So, now we
have a problem: if dnf behaves differently from yum, is it an improvement or
a regression? We don't know, and it's not clear to me how to tell; every
divergence is a potential bug in dnf, and therefore should be reported as
such.
I would venture a comment that it was a mistake to declare dnf a
separate
project, because it leads to a different approach to such differences. If it
was an evolutionary change in yum, it would be natural to expect it to
behave in a compatible way, and consequently detect and explain in more
detail the divergent behavior. By declaring a clean break, you are basically
saying that there is no need to explain the diffs, but the flip side of it
is that unless I can clearly understand why the difference is for the
better, I must suspect this to be a regression and report it.
As a result, dnf will have a huge bug load that is hard to work with
because
it depends on a specific state of the repositories at that specific moment
in time. Do you have a capability to investigate such problems?
Yes, we have.
"dnf --debugsolver" helps us a lot.
Here's a specific one, a firefox update from this morning that
shows up in
yum but not in dnf. I will submit it to bugzilla, just to see where we go
with that.
# dnf update firefox
Using metadata from Fri Apr 3 03:24:08 2015
Dependencies resolved.
Nothing to do.
# yum update firefox
Loaded plugins: auto-update-debuginfo, langpacks
Resolving Dependencies
--> Running transaction check
---> Package firefox.x86_64 0:37.0-2.fc21 will be updated
---> Package firefox.x86_64 0:37.0.1-1.fc21 will be an update
--> Finished Dependency Resolution
# dnf info firefox
Using metadata from Fri Apr 3 03:24:08 2015
Installed Packages
Name : firefox
Arch : x86_64
Epoch : 0
Version : 37.0
Release : 2.fc21
...
# yum info firefox
Loaded plugins: auto-update-debuginfo, langpacks
Installed Packages
Name : firefox
Arch : x86_64
Version : 37.0
Release : 2.fc21
...
Available Packages
Name : firefox
Arch : x86_64
Version : 37.0.1
Release : 1.fc21
Size : 69 M
Repo : updates/21/x86_64
...
--
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
--
Radek Holý
Associate Software Engineer
Software Management Team
Red Hat Czech
2:25 a.m.
-- snip --
I would venture a comment that it was a mistake to declare dnf a
separate project, because it leads to a different approach to such
differences. If it was an evolutionary change in yum, it would be
natural to expect it to behave in a compatible way, and consequently
detect and explain in more detail the divergent behavior. By declaring a
clean break, you are basically saying that there is no need to explain
the diffs, but the flip side of it is that unless I can clearly
understand why the difference is for the better, I must suspect this to
be a regression and report it.
To address this general concern, dnf actually has an extensive documentation
that describes the expected differences:
http://dnf.readthedocs.org/en/latest/
-- snip --
Thanks
Jan
7:22 a.m.
----- Original Message -----
From: "Bruno Wolff III" <bruno(a)wolff.to>
To: devel(a)lists.fedoraproject.org
Sent: Tuesday, April 7, 2015 5:51:41 PM
Subject: Re: dnf replacing yum and dnf-yum
On Tue, Apr 07, 2015 at 09:07:08 -0600,
Kevin Fenzi <kevin(a)scrye.com> wrote:
>
>dnf's default behavior is like yum with --skip-broken already.
This recurrent half-truth causes so much confusion. I'd like to ask everyone not to
repeat it. Or at least also point to
http://dnf.readthedocs.org/en/latest/cli_vs_yum.html#no-skip-broken please.
Not when installing packages.
AFAIK, YUM's --skip-broken does two things:
1) it selects another version of the requested package if the most suitable cannot be
installed
2) it skips the requested package if none of its versions can be installed
DNF does only (1) by default (and it can be disabled by --best). And it does it during
both upgrades and installations. But only if the requested "pkg-spec" matches
multiple packages. If the given "pkg-spec" is unique (e.g. foo-1-0.fc21.noarch)
and the matching package cannot be installed, DNF fails.
(2) was intentionally not supported in DNF so far but we have been repeatedly receiving
bug reports complaining that this "feature" is missing. We have finally received
a use case for it and thus we are considering an implementation as a plugin.
>
>If thats not working and you need to find out more, add '--best' to see
>things without 'skip-broken'.
My understanding is that --best can erase stuff (outside of obsoletes)
and I don't want to do that in scripts.
>If that still doesn't work, please file a bug. ;)
I have already filed some bugs and RFEs since dnf replaced yum in rawhide,
including about needing --skip-broken like functionallity for installs.
--
Radek Holý
Associate Software Engineer
Software Management Team
Red Hat Czech
10:03 a.m.
On Wed, Apr 08, 2015 at 08:22:53 -0400,
Radek Holy <rholy(a)redhat.com> wrote:
AFAIK, YUM's --skip-broken does two things:
1) it selects another version of the requested package if the most suitable cannot be
installed
2) it skips the requested package if none of its versions can be installed
(2) was intentionally not supported in DNF so far but we have been repeatedly receiving
bug reports complaining that this "feature" is missing. We have finally received
a use case for it and thus we are considering an implementation as a plugin.
Doesn't 2 apply if no package list is given for dnf update?
4:30 a.m.
----- Original Message -----
From: "Bruno Wolff III" <bruno(a)wolff.to>
To: "Radek Holy" <rholy(a)redhat.com>
Cc: "Development discussions related to Fedora"
<devel(a)lists.fedoraproject.org>
Sent: Wednesday, April 8, 2015 5:03:46 PM
Subject: Re: dnf replacing yum and dnf-yum
On Wed, Apr 08, 2015 at 08:22:53 -0400,
Radek Holy <rholy(a)redhat.com> wrote:
>
>AFAIK, YUM's --skip-broken does two things:
>1) it selects another version of the requested package if the most suitable
>cannot be installed
>2) it skips the requested package if none of its versions can be installed
>
>(2) was intentionally not supported in DNF so far but we have been
>repeatedly receiving bug reports complaining that this "feature" is
>missing. We have finally received a use case for it and thus we are
>considering an implementation as a plugin.
Doesn't 2 apply if no package list is given for dnf update?
Hm, well, in case of upgrade some version of the given package is already installed so
literally no (because the already installed version can be installed :-) ). But let's
say that we both are correct because upgrade is kind of special in this case. We can think
about changing the upgrade command to be consistent with the install command if there is a
demand to do that but so far I'm fine with the current situation. I think that in case
of upgrade, it's more common to ask to upgrade as much as you can while in case of
install, users/scripts prefer to install everything or fail otherwise. Moreover I think
that the change could annoy a lot of users.
So, let's say that (1) applies in both cases, (2) doesn't apply in case of install
and both does and doesn't (depending on the point of view) apply in case of upgrade
:-)
--
Radek Holý
Associate Software Engineer
Software Management Team
Red Hat Czech
5:10 a.m.
On 09/04/15 10:30, Radek Holy wrote:
> On Wed, Apr 08, 2015 at 08:22:53 -0400,
> Radek Holy <rholy(a)redhat.com> wrote:
>>
>> AFAIK, YUM's --skip-broken does two things:
>> 1) it selects another version of the requested package if the most suitable
>> cannot be installed
>> 2) it skips the requested package if none of its versions can be installed
>>
>> (2) was intentionally not supported in DNF so far but we have been
>> repeatedly receiving bug reports complaining that this "feature" is
>> missing. We have finally received a use case for it and thus we are
>> considering an implementation as a plugin.
>
> Doesn't 2 apply if no package list is given for dnf update?
>
Hm, well, in case of upgrade some version of the given package is already installed so
literally no (because the already installed version can be installed :-) ). But let's
say that we both are correct because upgrade is kind of special in this case. We can think
about changing the upgrade command to be consistent with the install command if there is a
demand to do that but so far I'm fine with the current situation. I think that in case
of upgrade, it's more common to ask to upgrade as much as you can while in case of
install, users/scripts prefer to install everything or fail otherwise. Moreover I think
that the change could annoy a lot of users.
Sounds reasonable, but include distro-sync in the upgrade case please...
That was one of the issues I ran into the other day, where I did
something like "dnf distro-sync b*" and if failed because one of the
installed packages which matched the wildcard didn't exist in any repo.
Tom
--
Tom Hughes (tom(a)compton.nu)
http://compton.nu/
5:11 a.m.
On 09/04/15 11:10, Tom Hughes wrote:
On 09/04/15 10:30, Radek Holy wrote:
>> On Wed, Apr 08, 2015 at 08:22:53 -0400,
>> Radek Holy <rholy(a)redhat.com> wrote:
>>>
>>> AFAIK, YUM's --skip-broken does two things:
>>> 1) it selects another version of the requested package if the most
>>> suitable
>>> cannot be installed
>>> 2) it skips the requested package if none of its versions can be
>>> installed
>>>
>>> (2) was intentionally not supported in DNF so far but we have been
>>> repeatedly receiving bug reports complaining that this "feature"
is
>>> missing. We have finally received a use case for it and thus we are
>>> considering an implementation as a plugin.
>>
>> Doesn't 2 apply if no package list is given for dnf update?
>>
>
> Hm, well, in case of upgrade some version of the given package is
> already installed so literally no (because the already installed
> version can be installed :-) ). But let's say that we both are correct
> because upgrade is kind of special in this case. We can think about
> changing the upgrade command to be consistent with the install command
> if there is a demand to do that but so far I'm fine with the current
> situation. I think that in case of upgrade, it's more common to ask to
> upgrade as much as you can while in case of install, users/scripts
> prefer to install everything or fail otherwise. Moreover I think that
> the change could annoy a lot of users.
Sounds reasonable, but include distro-sync in the upgrade case please...
That was one of the issues I ran into the other day, where I did
something like "dnf distro-sync b*" and if failed because one of the
installed packages which matched the wildcard didn't exist in any repo.
Hmm. Think I misread a bit what you were talking about, but my request
still stands ;-)
Tom
--
Tom Hughes (tom(a)compton.nu)
http://compton.nu/
5:39 a.m.
----- Original Message -----
From: "Tom Hughes" <tom(a)compton.nu>
To: "Development discussions related to Fedora"
<devel(a)lists.fedoraproject.org>
Sent: Thursday, April 9, 2015 12:11:54 PM
Subject: Re: dnf replacing yum and dnf-yum
On 09/04/15 11:10, Tom Hughes wrote:
> On 09/04/15 10:30, Radek Holy wrote:
>
>>> On Wed, Apr 08, 2015 at 08:22:53 -0400,
>>> Radek Holy <rholy(a)redhat.com> wrote:
>>>>
>>>> AFAIK, YUM's --skip-broken does two things:
>>>> 1) it selects another version of the requested package if the most
>>>> suitable
>>>> cannot be installed
>>>> 2) it skips the requested package if none of its versions can be
>>>> installed
>>>>
>>>> (2) was intentionally not supported in DNF so far but we have been
>>>> repeatedly receiving bug reports complaining that this
"feature" is
>>>> missing. We have finally received a use case for it and thus we are
>>>> considering an implementation as a plugin.
>>>
>>> Doesn't 2 apply if no package list is given for dnf update?
>>>
>>
>> Hm, well, in case of upgrade some version of the given package is
>> already installed so literally no (because the already installed
>> version can be installed :-) ). But let's say that we both are correct
>> because upgrade is kind of special in this case. We can think about
>> changing the upgrade command to be consistent with the install command
>> if there is a demand to do that but so far I'm fine with the current
>> situation. I think that in case of upgrade, it's more common to ask to
>> upgrade as much as you can while in case of install, users/scripts
>> prefer to install everything or fail otherwise. Moreover I think that
>> the change could annoy a lot of users.
>
> Sounds reasonable, but include distro-sync in the upgrade case please...
>
> That was one of the issues I ran into the other day, where I did
> something like "dnf distro-sync b*" and if failed because one of the
> installed packages which matched the wildcard didn't exist in any repo.
Hmm. Think I misread a bit what you were talking about, but my request
still stands ;-)
Hm, I think that it depends on the use case. AFAIK, distro-sync is mostly used to upgrade
Fedora (an unsupported approach AFAIK) and to replace some testing/3rd-party versions of
package with the "official" ones. (BTW, I'd appreciate if anyone will share
their use case) While in the first case, I think that the upgrade's behaviour is
preferred, in the other case, the install's behaviour is better IMO. (Which
dangerously indicates that the --skip-broken switch is a good solution :( )
Anyway, file an RFE (if it isn't filed already) please. We can track/discuss it
there.
Thank you in advance
--
Radek Holý
Associate Software Engineer
Software Management Team
Red Hat Czech
10:53 a.m.
On 04/07/2015 05:07 PM, Kevin Fenzi wrote:
On Tue, 7 Apr 2015 08:38:57 -0500
Bruno Wolff III <bruno(a)wolff.to> wrote:
> On Tue, Apr 07, 2015 at 10:22:25 -0300,
> Paulo César Pereira de Andrade
> <paulo.cesar.pereira.de.andrade(a)gmail.com> wrote:
>>
>> I had also switched back to yum in rawhide due to --skip-broken,
>> and
>> in a few updates not even needing it (I would first see what is
>> broken, and if not something "vital", use --skip-broken), while dnf
>> would just fail with cryptic messages. I can keep up if kde or gnome
>> is broken, or some other stuff that does not prevent boot and a
>> functional system.
>
> dnf really does need --skip-broken like support if it is to replace
> yum. yum can be a lot faster than the needed work around to get dnf
> to work equivalently. I am considering going back to yum in rawhide
> rather than continuig to test dnf in rawhide because of this issue.
dnf's default behavior is like yum with --skip-broken already.
WHAT?
--skip-broken is a band-aid to work around packaging mistakes and bugs
and NOT be the default.
IMO, this kind of behavior is not helpful and therefore should be reverted.
If thats not working and you need to find out more, add
'--best' to see
things without 'skip-broken'.
If that still doesn't work, please file a bug. ;)
Ralf
11 a.m.
Am 07.04.2015 um 17:53 schrieb Ralf Corsepius:
On 04/07/2015 05:07 PM, Kevin Fenzi wrote:
> dnf's default behavior is like yum with --skip-broken already.
WHAT?
--skip-broken is a band-aid to work around packaging mistakes and bugs
and NOT be the default.
IMO, this kind of behavior is not helpful and therefore should be reverted
+1
that's unacceptable and leads in burry *real* problems resulting in
sonner or later security updates are broken and nobody take snotice soon
enough
11:30 a.m.
On Tue, Apr 07, 2015 at 18:00:47 +0200,
Reindl Harald <h.reindl(a)thelounge.net> wrote:
that's unacceptable and leads in burry *real* problems resulting in
sonner or later security updates are broken and nobody take snotice
soon enough
The skip broken feature is more likely to help someone get timely security
updates than prevent them.
11:39 a.m.
On 04/07/2015 06:30 PM, Bruno Wolff III wrote:
On Tue, Apr 07, 2015 at 18:00:47 +0200,
Reindl Harald <h.reindl(a)thelounge.net> wrote:
>
> that's unacceptable and leads in burry *real* problems resulting in
> sonner or later security updates are broken and nobody take snotice
> soon enough
The skip broken feature is more likely to help someone get timely
security updates than prevent them.
skip broken
- is pushing fedora users into chaotic situations.
- to cheat fedora users and to play down the "real problems".
In a perfect world skip-broken should not even exist.
Ralf
12:02 p.m.
W dniu 07.04.2015 o 18:39, Ralf Corsepius pisze:
skip broken
- is pushing fedora users into chaotic situations.
- to cheat fedora users and to play down the "real problems".
In a perfect world skip-broken should not even exist.
In a perfect world all Fedora packages would be always installable. And
would not require users to use external repositories for whatever they need.
But we do not live in such one.
For me "--best" was a switch to tell which rpmfusion packages block
updates (solved with manual rebuild of mplayer and all dependencies for
f22).
12:05 p.m.
Am 07.04.2015 um 19:02 schrieb Marcin Juszkiewicz:
W dniu 07.04.2015 o 18:39, Ralf Corsepius pisze:
> skip broken
> - is pushing fedora users into chaotic situations.
> - to cheat fedora users and to play down the "real problems".
>
> In a perfect world skip-broken should not even exist.
In a perfect world all Fedora packages would be always installable. And
would not require users to use external repositories for whatever they need.
But we do not live in such one.
For me "--best" was a switch to tell which rpmfusion packages block
updates (solved with manual rebuild of mplayer and all dependencies for
f22)
but with such *defaults* you make the world *worser*
* dependencies may be broken only on specific setups
* the user don't take notice
* the user don't get a possible important update
* the user won't file a bugreport because he don#t know
when something on my system has problems *i ant to know* that and i can
type --skip-broken at my own to get other updates *while* write a
bugreport to get the other problem fixed
5:46 a.m.
On 04/07/2015 07:05 PM, Reindl Harald wrote:
Am 07.04.2015 um 19:02 schrieb Marcin Juszkiewicz:
> W dniu 07.04.2015 o 18:39, Ralf Corsepius pisze:
>
>> skip broken
>> - is pushing fedora users into chaotic situations.
>> - to cheat fedora users and to play down the "real problems".
>>
>> In a perfect world skip-broken should not even exist.
>
> In a perfect world all Fedora packages would be always installable. And
> would not require users to use external repositories for whatever they
> need.
>
> But we do not live in such one.
>
> For me "--best" was a switch to tell which rpmfusion packages block
> updates (solved with manual rebuild of mplayer and all dependencies for
> f22)
but with such *defaults* you make the world *worser*
* dependencies may be broken only on specific setups
* the user don't take notice
* the user don't get a possible important update
* the user won't file a bugreport because he don#t know
when something on my system has problems *i ant to know* that and i can
type --skip-broken at my own to get other updates *while* write a
bugreport to get the other problem fixed
Exactly. With dnf you would not even know there are broken packages. All
you'd see is no updates being installed and believe everything is OK -
In fact you are seeing the silence of death.
That said, with dnf one broken single dep of a central package would
suffice to lock out a whole tree of packages. It doesn't really need
much visionary power to construct such cases.
Just think about what recently has happened this week in F21: (probably
unnoticed to the fast majority of users): Somebody pushed an
SONAME-changing/ABI-braking update to cloog, cloog-ppl, isl.
This broke all packages which were depending the old libcloog.so.
Seemingly there weren't any in Fedora, but 3rd party repos may carry such.
Ralf
ETC: FESCO, revert the decision to use dnf on F22 and send the dnf-devs
back to the drawing boards.
9:24 a.m.
W dniu 10.04.2015 o 12:46, Ralf Corsepius pisze:
Just think about what recently has happened this week in F21:
(probably unnoticed to the fast majority of users): Somebody pushed
an SONAME-changing/ABI-braking update to cloog, cloog-ppl, isl.
This broke all packages which were depending the old libcloog.so.
Seemingly there weren't any in Fedora, but 3rd party repos may carry
such.
And magically that became DNF issue? Such fuckup (sorry, but there is no
better word) is rather example of bad package repo management. F21 is
RELEASED version - none of such soname changes should happen there.
I know, I came from Debian/Ubuntu world where things are done in other
way but a way how Fedora is developed AFTER it gets released scares me
too often.
9:27 a.m.
none of such soname changes should happen there
Exactly, it should not. I think this is a mistake of the maintainer and
not Fedora. I certainly think twice about my Fedora updates.
J.
----- Original Message -----
From: "Marcin Juszkiewicz" <mjuszkiewicz(a)redhat.com>
To: devel(a)lists.fedoraproject.org
Sent: Friday, April 10, 2015 4:24:38 PM
Subject: Re: dnf replacing yum and dnf-yum
W dniu 10.04.2015 o 12:46, Ralf Corsepius pisze:
Just think about what recently has happened this week in F21:
(probably unnoticed to the fast majority of users): Somebody pushed
an SONAME-changing/ABI-braking update to cloog, cloog-ppl, isl.
This broke all packages which were depending the old libcloog.so.
Seemingly there weren't any in Fedora, but 3rd party repos may carry
such.
And magically that became DNF issue? Such fuckup (sorry, but there is no
better word) is rather example of bad package repo management. F21 is
RELEASED version - none of such soname changes should happen there.
I know, I came from Debian/Ubuntu world where things are done in other
way but a way how Fedora is developed AFTER it gets released scares me
too often.
--
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
9:30 a.m.
Am 10.04.2015 um 16:24 schrieb Marcin Juszkiewicz:
W dniu 10.04.2015 o 12:46, Ralf Corsepius pisze:
> Just think about what recently has happened this week in F21:
> (probably unnoticed to the fast majority of users): Somebody pushed
> an SONAME-changing/ABI-braking update to cloog, cloog-ppl, isl.
>
> This broke all packages which were depending the old libcloog.so.
> Seemingly there weren't any in Fedora, but 3rd party repos may carry
> such.
And magically that became DNF issue? Such fuckup (sorry, but there is no
better word) is rather example of bad package repo management. F21 is
RELEASED version - none of such soname changes should happen there
who cares what should or should not be while we have to struggle with
the real world as it is?
10:31 a.m.
On Apr 10, 2015 4:39 AM, "Radek Holy" <rholy(a)redhat.com> wrote:
> Hm, I think that it depends on the use case. AFAIK,
distro-sync is mostly
used to upgrade Fedora (an unsupported approach AFAIK) and to replace some
testing/3rd-party versions of package with the "official" ones. (BTW, I'd
appreciate if anyone will share their use case) While in the first case, I
think that the upgrade's behaviour is preferred, in the other case, the
install's behaviour is better IMO. (Which dangerously indicates that the
--skip-broken switch is a good solution :( )
> Anyway, file an RFE (if it isn't filed already)
please. We can
track/discuss it there.
> Thank you in advance
> --
> Radek Holý
(lots of trimming, and skipping an RFE, as this just pertains to the
distro-sync use case question)
distro-sync is useful for getting to a sane state after temporarily
enabling some repo that interacts with the primary ones. This can happen
with third party repos, but we can consider an entirely in-house situation:
The user finds a bug in widget-2.5.7 and reports it. A fix for widget is
shipped and the user is asked to test via `dnf update widget --enablerepo
updates-testing`. The transaction pulls in many requires from
updates-testing (although at this point, I realize dnf may not be upgrading
the requires in this transaction if they are not versioned). The new
widget is tested, life goes on.
Later, the user wants to install or update some package whizbang that
shares requires with widget. That package has versioned requires on
packages from the updates repo, but some of the installed packages are from
updates-testing and don't provide what whizbang needs.
Something like `dnf --allowerasing install whizbang` might be the
appropriate and precise tool to get through that transaction. `dnf
distro-sync` is the less precise, big-hammer tool for the user that doesn't
know or care to track down the intricacies of widget and whizbang
dependencies. They ran some command from a bug report a while ago and
moved on, and now they run distro-sync to return their system to a
known-good state and move on.
This sort of thing is most common during the prerelease cycle, when users
will have updates-testing on then off, and there are freezes, and
branching, and lots of activity that might leave early adopters in an
unsane state.
And yeah, it is very useful for upgrades. Even when ran after a proper
fedup upgrade.
--Pete
6:07 a.m.
----- Original Message -----
From: "Pete Travis" <lists(a)petetravis.com>
To: "Development discussions related to Fedora"
<devel(a)lists.fedoraproject.org>
Sent: Friday, April 10, 2015 5:31:08 PM
Subject: Re: dnf replacing yum and dnf-yum
On Apr 10, 2015 4:39 AM, "Radek Holy" < rholy(a)redhat.com
> wrote:
>
>
> Hm, I think that it depends on the use case. AFAIK, distro-sync is mostly
> used to upgrade Fedora (an unsupported approach AFAIK) and to replace some
> testing/3rd-party versions of package with the "official" ones. (BTW,
I'd
> appreciate if anyone will share their use case) While in the first case, I
> think that the upgrade's behaviour is preferred, in the other case, the
> install's behaviour is better IMO. (Which dangerously indicates that the
> --skip-broken switch is a good solution :( )
>
> Anyway, file an RFE (if it isn't filed already) please. We can
> track/discuss it there.
>
> Thank you in advance
> --
> Radek Holý
>
(lots of trimming, and skipping an RFE, as this just pertains to the
distro-sync use case question)
distro-sync is useful for getting to a sane state after temporarily
enabling
some repo that interacts with the primary ones. This can happen with third
party repos, but we can consider an entirely in-house situation:
The user finds a bug in widget-2.5.7 and reports it. A fix for widget
is
shipped and the user is asked to test via `dnf update widget --enablerepo
updates-testing`. The transaction pulls in many requires from
updates-testing (although at this point, I realize dnf may not be upgrading
the requires in this transaction if they are not versioned). The new widget
is tested, life goes on.
Later, the user wants to install or update some package whizbang that
shares
requires with widget. That package has versioned requires on packages from
the updates repo, but some of the installed packages are from
updates-testing and don't provide what whizbang needs.
Something like `dnf --allowerasing install whizbang` might be the
appropriate
and precise tool to get through that transaction. `dnf distro-sync` is the
less precise, big-hammer tool for the user that doesn't know or care to
track down the intricacies of widget and whizbang dependencies. They ran
some command from a bug report a while ago and moved on, and now they run
distro-sync to return their system to a known-good state and move on.
This sort of thing is most common during the prerelease cycle, when
users
will have updates-testing on then off, and there are freezes, and branching,
and lots of activity that might leave early adopters in an unsane state.
And yeah, it is very useful for upgrades. Even when ran after a
proper fedup
upgrade.
--Pete
Yeah, that's basically what I meant by 'replace some testing versions of package
with the "official" ones'. Anyway, thank you for elaborating on it. I'll
definitely make a test case from it.
I'd like to let those doing the actions described above know that there is also a not
very well known command "dnf repository-packages <repoid>
remove-or-distro-sync" which is specifically designed for switching from packages
installed from testing/3rd-party repositories
--
Radek Holý
Associate Software Engineer
Software Management Team
Red Hat Czech
10:18 a.m.
On Apr 13, 2015 5:07 AM, "Radek Holy" <rholy(a)redhat.com> wrote:
________________________________
>
> From: "Pete Travis" <lists(a)petetravis.com>
> To: "Development discussions related to Fedora" <
devel(a)lists.fedoraproject.org>
> Sent: Friday, April 10, 2015 5:31:08 PM
> Subject: Re: dnf replacing yum and dnf-yum
>
>
>
> On Apr 10, 2015 4:39 AM, "Radek Holy" <rholy(a)redhat.com> wrote:
> >
>
> >
> > Hm, I think that it depends on the use case. AFAIK, distro-sync is
mostly
used to upgrade Fedora (an unsupported approach AFAIK) and to
replace some testing/3rd-party versions of package with the "official"
ones. (BTW, I'd appreciate if anyone will share their use case) While in
the first case, I think that the upgrade's behaviour is preferred, in the
other case, the install's behaviour is better IMO. (Which dangerously
indicates that the --skip-broken switch is a good solution :( )
> >
> > Anyway, file an RFE (if it isn't filed already) please. We can
track/discuss it there.
> >
> > Thank you in advance
> > --
> > Radek Holý
> >
>
> (lots of trimming, and skipping an RFE, as this just pertains to the
distro-sync use case question)
>
> distro-sync is useful for getting to a sane state after temporarily
enabling
some repo that interacts with the primary ones. This can happen
with third party repos, but we can consider an entirely in-house situation:
>
> The user finds a bug in widget-2.5.7 and reports it. A fix for widget
is
shipped and the user is asked to test via `dnf update widget
--enablerepo updates-testing`. The transaction pulls in many requires from
updates-testing (although at this point, I realize dnf may not be upgrading
the requires in this transaction if they are not versioned). The new
widget is tested, life goes on.
>
> Later, the user wants to install or update some package whizbang that
shares
requires with widget. That package has versioned requires on
packages from the updates repo, but some of the installed packages are from
updates-testing and don't provide what whizbang needs.
>
> Something like `dnf --allowerasing install whizbang` might be the
appropriate
and precise tool to get through that transaction. `dnf
distro-sync` is the less precise, big-hammer tool for the user that doesn't
know or care to track down the intricacies of widget and whizbang
dependencies. They ran some command from a bug report a while ago and
moved on, and now they run distro-sync to return their system to a
known-good state and move on.
>
> This sort of thing is most common during the prerelease cycle, when
users will
have updates-testing on then off, and there are freezes, and
branching, and lots of activity that might leave early adopters in an
unsane state.
>
> And yeah, it is very useful for upgrades. Even when ran after a proper
fedup
upgrade.
>
> --Pete
>
>
Yeah, that's basically what I meant by 'replace some testing versions of
package with the "official" ones'. Anyway, thank you for elaborating
on it.
I'll definitely make a test case from it.
I'd like to let those doing the actions described above know that there
is also
a not very well known command "dnf repository-packages <repoid>
remove-or-distro-sync" which is specifically designed for switching from
packages installed from testing/3rd-party repositories
--
Radek Holý
Associate Software Engineer
Software Management Team
Red Hat Czech
--
Nice! That's <repoid> as the stable/updates repo, not the
testing/3rd-party/problem repo, right? I'll add this to my dnf writeup.
--Pete
12:20 p.m.
----- Original Message -----
From: "Pete Travis" <lists(a)petetravis.com>
To: "Development discussions related to Fedora"
<devel(a)lists.fedoraproject.org>
Sent: Tuesday, April 14, 2015 5:18:15 PM
Subject: Re: dnf replacing yum and dnf-yum
On Apr 13, 2015 5:07 AM, "Radek Holy" < rholy(a)redhat.com
> wrote:
>
>
> ________________________________
>>
>> From: "Pete Travis" < lists(a)petetravis.com >
>> To: "Development discussions related to Fedora" <
>> devel(a)lists.fedoraproject.org >
>> Sent: Friday, April 10, 2015 5:31:08 PM
>> Subject: Re: dnf replacing yum and dnf-yum
>>
>>
>>
>> On Apr 10, 2015 4:39 AM, "Radek Holy" < rholy(a)redhat.com >
wrote:
>> >
>>
>> >
>> > Hm, I think that it depends on the use case. AFAIK, distro-sync is
>> > mostly used to upgrade Fedora (an unsupported approach AFAIK) and to
>> > replace some testing/3rd-party versions of package with the
"official"
>> > ones. (BTW, I'd appreciate if anyone will share their use case) While
>> > in the first case, I think that the upgrade's behaviour is preferred,
>> > in the other case, the install's behaviour is better IMO. (Which
>> > dangerously indicates that the --skip-broken switch is a good solution
>> > :( )
>> >
>> > Anyway, file an RFE (if it isn't filed already) please. We can
>> > track/discuss it there.
>> >
>> > Thank you in advance
>> > --
>> > Radek Holý
>> >
>>
>> (lots of trimming, and skipping an RFE, as this just pertains to the
>> distro-sync use case question)
>>
>> distro-sync is useful for getting to a sane state after temporarily
>> enabling some repo that interacts with the primary ones. This can happen
>> with third party repos, but we can consider an entirely in-house
>> situation:
>>
>> The user finds a bug in widget-2.5.7 and reports it. A fix for widget is
>> shipped and the user is asked to test via `dnf update widget --enablerepo
>> updates-testing`. The transaction pulls in many requires from
>> updates-testing (although at this point, I realize dnf may not be
>> upgrading the requires in this transaction if they are not versioned).
>> The new widget is tested, life goes on.
>>
>> Later, the user wants to install or update some package whizbang that
>> shares requires with widget. That package has versioned requires on
>> packages from the updates repo, but some of the installed packages are
>> from updates-testing and don't provide what whizbang needs.
>>
>> Something like `dnf --allowerasing install whizbang` might be the
>> appropriate and precise tool to get through that transaction. `dnf
>> distro-sync` is the less precise, big-hammer tool for the user that
>> doesn't know or care to track down the intricacies of widget and whizbang
>> dependencies. They ran some command from a bug report a while ago and
>> moved on, and now they run distro-sync to return their system to a
>> known-good state and move on.
>>
>> This sort of thing is most common during the prerelease cycle, when users
>> will have updates-testing on then off, and there are freezes, and
>> branching, and lots of activity that might leave early adopters in an
>> unsane state.
>>
>> And yeah, it is very useful for upgrades. Even when ran after a proper
>> fedup upgrade.
>>
>
--Pete
>>
>>
> Yeah, that's basically what I meant by 'replace some testing versions of
> package with the "official" ones'. Anyway, thank you for elaborating
on
> it. I'll definitely make a test case from it.
>
> I'd like to let those doing the actions described above know that there is
> also a not very well known command "dnf repository-packages <repoid>
> remove-or-distro-sync" which is specifically designed for switching from
> packages installed from testing/3rd-party repositories
> --
> Radek Holý
> Associate Software Engineer
> Software Management Team
> Red Hat Czech
>
> -- Nice! That's <repoid> as the stable/updates repo, not the
testing/3rd-party/problem repo, right? I'll add this to my dnf writeup.
--Pete
No, <repoid> as the testing/3rd-party/problem repo. It selects the packages
installed from <repoid> and runs distro-sync or remove on them while the
upgrades/downgrades are taken from all the enabled repositories except <repoid>. So,
in the end, it's very likely that you'll end up with an RPMDB that does not
contain any package installed from <repoid>.
This command was taken from YUM and although it is not sometimes clear what the command
should do without looking into man pages, I think that it's good as it is.
If you want to control from which repositories are the upgrades/downgrades taken, combine
it with --disablerepo, --enablerepo.
--
Radek Holý
Associate Software Engineer
Software Management Team
Red Hat Czech
11:55 a.m.
Am 07.04.2015 um 18:30 schrieb Bruno Wolff III:
On Tue, Apr 07, 2015 at 18:00:47 +0200,
Reindl Harald <h.reindl(a)thelounge.net> wrote:
>
> that's unacceptable and leads in burry *real* problems resulting in
> sonner or later security updates are broken and nobody take snotice
> soon enough
The skip broken feature is more likely to help someone get timely
security updates than prevent them
really?
it masks the existence of a security update with broken deps and we
*really* don't need another flamewar thread - it is a bad attitude to
make such options the default
12:08 p.m.
On Tue, Apr 07, 2015 at 18:55:38 +0200,
Reindl Harald <h.reindl(a)thelounge.net> wrote:
it masks the existence of a security update with broken deps and we
*really* don't need another flamewar thread - it is a bad attitude to
make such options the default
I think it's much more likely there is a good security update available
but a broken update for some other package which would block doing the
security update in the absence of the skip broken feature.
Skip broken isn't going to have that much effect on not noticing that
a security update is broken. There are other tools for helping with that
when the brokenness is contained within Fedora.
12:13 p.m.
Am 07.04.2015 um 19:08 schrieb Bruno Wolff III:
On Tue, Apr 07, 2015 at 18:55:38 +0200,
Reindl Harald <h.reindl(a)thelounge.net> wrote:
>
> it masks the existence of a security update with broken deps and we
> *really* don't need another flamewar thread - it is a bad attitude to
> make such options the default
I think it's much more likely there is a good security update available
but a broken update for some other package which would block doing the
security update in the absence of the skip broken feature.
Skip broken isn't going to have that much effect on not noticing that a
security update is broken. There are other tools for helping with that
when the brokenness is contained within Fedora
jesus chirst it *does not matter* what is more or less likely
burry errors is *wrong* in any case and there is also a world outside
"within fedora" and the Fedora repos itself
11:33 a.m.
On Tue, Apr 7, 2015 at 6:00 PM, Reindl Harald <h.reindl(a)thelounge.net> wrote:
Am 07.04.2015 um 17:53 schrieb Ralf Corsepius:
>
> On 04/07/2015 05:07 PM, Kevin Fenzi wrote:
>>
>> dnf's default behavior is like yum with --skip-broken already.
>
>
> WHAT?
>
> --skip-broken is a band-aid to work around packaging mistakes and bugs
> and NOT be the default.
>
> IMO, this kind of behavior is not helpful and therefore should be reverted
+1
that's unacceptable and leads in burry *real* problems resulting in sonner
or later security updates are broken and nobody take snotice soon enough
The bug is elsewhere though ... i.e. that is even possible to push
updates with broken deps.
Rawhide is a different story but everything that goes through bodhi
(stable releases and branched) should simply refuse pushes with broken
deps.
As for security updates well you don't want a random third party repo
to break halt your upgrade transactions due to a broken dep and cause
security updates to not get installed.
11:37 a.m.
On Tue, 2015-04-07 at 18:33 +0200, drago01 wrote:
On Tue, Apr 7, 2015 at 6:00 PM, Reindl Harald
<h.reindl(a)thelounge.net
> wrote:
>
>
> Am 07.04.2015 um 17:53 schrieb Ralf Corsepius:
> >
> > On 04/07/2015 05:07 PM, Kevin Fenzi wrote:
> > >
> > > dnf's default behavior is like yum with --skip-broken already.
> >
> >
> > WHAT?
> >
> > --skip-broken is a band-aid to work around packaging mistakes
> > and bugs
> > and NOT be the default.
> >
> > IMO, this kind of behavior is not helpful and therefore should
> > be reverted
>
>
> +1
>
> that's unacceptable and leads in burry *real* problems resulting
> in sonner
> or later security updates are broken and nobody take snotice soon
> enough
The bug is elsewhere though ... i.e. that is even possible to push
updates with broken deps.
Rawhide is a different story but everything that goes through bodhi
(stable releases and branched) should simply refuse pushes with
broken
deps.
This is easier said than done. We don't have a perfect dependency
checker and it's not at all easy to write one. tflink and John Dulaney
have more details if you're interested, but yes, this is not a trivial
thing we can just wave a wand and make happen.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
3:55 a.m.
On 7 April 2015 at 17:37, Adam Williamson <adamwill(a)fedoraproject.org> wrote:
This is easier said than done. We don't have a perfect
dependency
checker and it's not at all easy to write one.
From someone that's actually written a yum-compatible dependency
checker in C several years ago[1] I can attest that the --skip-broken
flag is really only a work around for repositories being pushed while
broken, or the depsolver being broken by design. We tried using
--skip-broken by default in PackageKit a few years ago and it was
basically a disaster.
A "simple" iterative depsolver like yum has needs so many special
cases that it becomes a maze of code making pretty random decisions,
requiring spurious manual deps added to packages when upgrade issues
were found. Ten years ago cleverer people than me decided that
SAT-based solvers were the only thing that made logical sense, which
is what hawkey uses via the libsolv library. PackageKit in F22 uses
hawkey, and the code is predictable and stable, which is a long way
from what we had with the yum depsolver.
To those mis-remembering how awesome the yum depsolver was: it really wasn't.
Richard
[1] https://github.com/hughsie/zif
4:05 a.m.
On Tue, Apr 7, 2015 at 6:37 PM, Adam Williamson
<adamwill(a)fedoraproject.org> wrote:
On Tue, 2015-04-07 at 18:33 +0200, drago01 wrote:
> On Tue, Apr 7, 2015 at 6:00 PM, Reindl Harald <h.reindl(a)thelounge.net
> > wrote:
> >
> >
> > Am 07.04.2015 um 17:53 schrieb Ralf Corsepius:
> > >
> > > On 04/07/2015 05:07 PM, Kevin Fenzi wrote:
> > > >
> > > > dnf's default behavior is like yum with --skip-broken already.
> > >
> > >
> > > WHAT?
> > >
> > > --skip-broken is a band-aid to work around packaging mistakes
> > > and bugs
> > > and NOT be the default.
> > >
> > > IMO, this kind of behavior is not helpful and therefore should
> > > be reverted
> >
> >
> > +1
> >
> > that's unacceptable and leads in burry *real* problems resulting
> > in sonner
> > or later security updates are broken and nobody take snotice soon
> > enough
>
> The bug is elsewhere though ... i.e. that is even possible to push
> updates with broken deps.
> Rawhide is a different story but everything that goes through bodhi
> (stable releases and branched) should simply refuse pushes with
> broken
> deps.
This is easier said than done. We don't have a perfect dependency
checker and it's not at all easy to write one. tflink and John Dulaney
have more details if you're interested, but yes, this is not a trivial
thing we can just wave a wand and make happen.
We do have dep solvers otherwise no one would notice that a dep is
broken ever. (like libsolv + hawkey).
So what bodhi should do is to ask "has this package all dependencies
satisfied with base + updates + other packages in this push" for every
package in the push.
If the answer is "no" for a package cancel the push; remove it;
restart and only push the once that has satisfied deps.
Report the failed once to the maintainers so that they can fix it.
4:17 a.m.
W dniu 08.04.2015 o 11:05, drago01 pisze:
We do have dep solvers otherwise no one would notice that a dep is
broken ever. (like libsolv + hawkey).
So what bodhi should do is to ask "has this package all dependencies
satisfied with base + updates + other packages in this push" for every
package in the push.
If the answer is "no" for a package cancel the push; remove it;
restart and only push the once that has satisfied deps.
Report the failed once to the maintainers so that they can fix it.
When I was Debian/Ubuntu developer it was easy. Pbuilder had hooks and
one of them in my setup was "once built, install all resulting packages".
This way as a developer I could check are results usable. Not found
something like that in mock.
12:53 p.m.
>>>> "MJ" == Marcin Juszkiewicz
<mjuszkiewicz(a)redhat.com> writes:
MJ> When I was Debian/Ubuntu developer it was easy. Pbuilder had hooks
MJ> and one of them in my setup was "once built, install all resulting
MJ> packages".
MJ> This way as a developer I could check are results usable. Not found
MJ> something like that in mock.
For every local mock build, my script installs the built package and
runs rpmlint on them (which catches more things than just running
rpmlint on the rpms). That's one of the things I've really missed about
fedora-review.
To install the built packages, you just have to run
mock --install $MOCKDIR/result/*{i686,x86_64,noarch}.rpm
adjusting $MOCKDIR appropriately, of course. Probably trivial to do
with a mock plugin. For testing of "easy" things, you can even do a
mock shell and run the code out of the chroot.
- J<
7:13 a.m.
On 2015-04-08 11:17, Marcin Juszkiewicz wrote:
W dniu 08.04.2015 o 11:05, drago01 pisze:
> We do have dep solvers otherwise no one would notice that a dep is
> broken ever. (like libsolv + hawkey).
> So what bodhi should do is to ask "has this package all dependencies
> satisfied with base + updates + other packages in this push" for every
> package in the push.
> If the answer is "no" for a package cancel the push; remove it;
> restart and only push the once that has satisfied deps.
> Report the failed once to the maintainers so that they can fix it.
When I was Debian/Ubuntu developer it was easy. Pbuilder had hooks and
one of them in my setup was "once built, install all resulting packages".
This way as a developer I could check are results usable. Not found
something like that in mock.
Curent mock has such option:
--postinstall
Try to install built packages in the same buildroot right after build.
Michael Simacek
5:11 a.m.
On Wed, 8 Apr 2015 at 11:05 drago01 <drago01(a)gmail.com> wrote:
On Tue, Apr 7, 2015 at 6:37 PM, Adam Williamson
<adamwill(a)fedoraproject.org> wrote:
> On Tue, 2015-04-07 at 18:33 +0200, drago01 wrote:
>> On Tue, Apr 7, 2015 at 6:00 PM, Reindl Harald <h.reindl(a)thelounge.net
>> > wrote:
>> >
>> >
>> > Am 07.04.2015 um 17:53 schrieb Ralf Corsepius:
>> > >
>> > > On 04/07/2015 05:07 PM, Kevin Fenzi wrote:
>> > > >
>> > > > dnf's default behavior is like yum with --skip-broken
already.
>> > >
>> > >
>> > > WHAT?
>> > >
>> > > --skip-broken is a band-aid to work around packaging mistakes
>> > > and bugs
>> > > and NOT be the default.
>> > >
>> > > IMO, this kind of behavior is not helpful and therefore should
>> > > be reverted
>> >
>> >
>> > +1
>> >
>> > that's unacceptable and leads in burry *real* problems resulting
>> > in sonner
>> > or later security updates are broken and nobody take snotice soon
>> > enough
>>
>> The bug is elsewhere though ... i.e. that is even possible to push
>> updates with broken deps.
>> Rawhide is a different story but everything that goes through bodhi
>> (stable releases and branched) should simply refuse pushes with
>> broken
>> deps.
>
> This is easier said than done. We don't have a perfect dependency
> checker and it's not at all easy to write one. tflink and John Dulaney
> have more details if you're interested, but yes, this is not a trivial
> thing we can just wave a wand and make happen.
We do have dep solvers otherwise no one would notice that a dep is
broken ever. (like libsolv + hawkey).
So what bodhi should do is to ask "has this package all dependencies
satisfied with base + updates + other packages in this push" for every
package in the push.
If the answer is "no" for a package cancel the push; remove it;
restart and only push the once that has satisfied deps.
Report the failed once to the maintainers so that they can fix it.
It is not so simple, you have to test all combinations for packages
requiring an updated package and all the packages there requires someting
provided by previous version of the package, with thousend of packages and
multiple packages providing the same stuff, it is an almost impossible task.
Tim
7:56 a.m.
On Wed, Apr 8, 2015 at 12:11 PM, Tim Lauridsen <tim.lauridsen(a)gmail.com> wrote:
On Wed, 8 Apr 2015 at 11:05 drago01 <drago01(a)gmail.com> wrote:
>
> On Tue, Apr 7, 2015 at 6:37 PM, Adam Williamson
> <adamwill(a)fedoraproject.org> wrote:
> > On Tue, 2015-04-07 at 18:33 +0200, drago01 wrote:
> >> On Tue, Apr 7, 2015 at 6:00 PM, Reindl Harald <h.reindl(a)thelounge.net
> >> > wrote:
> >> >
> >> >
> >> > Am 07.04.2015 um 17:53 schrieb Ralf Corsepius:
> >> > >
> >> > > On 04/07/2015 05:07 PM, Kevin Fenzi wrote:
> >> > > >
> >> > > > dnf's default behavior is like yum with --skip-broken
already.
> >> > >
> >> > >
> >> > > WHAT?
> >> > >
> >> > > --skip-broken is a band-aid to work around packaging mistakes
> >> > > and bugs
> >> > > and NOT be the default.
> >> > >
> >> > > IMO, this kind of behavior is not helpful and therefore should
> >> > > be reverted
> >> >
> >> >
> >> > +1
> >> >
> >> > that's unacceptable and leads in burry *real* problems resulting
> >> > in sonner
> >> > or later security updates are broken and nobody take snotice soon
> >> > enough
> >>
> >> The bug is elsewhere though ... i.e. that is even possible to push
> >> updates with broken deps.
> >> Rawhide is a different story but everything that goes through bodhi
> >> (stable releases and branched) should simply refuse pushes with
> >> broken
> >> deps.
> >
> > This is easier said than done. We don't have a perfect dependency
> > checker and it's not at all easy to write one. tflink and John Dulaney
> > have more details if you're interested, but yes, this is not a trivial
> > thing we can just wave a wand and make happen.
>
> We do have dep solvers otherwise no one would notice that a dep is
> broken ever. (like libsolv + hawkey).
> So what bodhi should do is to ask "has this package all dependencies
> satisfied with base + updates + other packages in this push" for every
> package in the push.
> If the answer is "no" for a package cancel the push; remove it;
> restart and only push the once that has satisfied deps.
> Report the failed once to the maintainers so that they can fix it.
>
It is not so simple, you have to test all combinations for packages
requiring an updated package and all the packages there requires someting
provided by previous version of the package, with thousend of packages and
multiple packages providing the same stuff, it is an almost impossible task.
Did you even read what I wrote?
7:06 p.m.
On Wed, 2015-04-08 at 14:56 +0200, drago01 wrote:
> It is not so simple, you have to test all combinations for packages
> requiring an updated package and all the packages there requires
> someting
> provided by previous version of the package, with thousend of
> packages and
> multiple packages providing the same stuff, it is an almost
> impossible task.
Did you even read what I wrote?
Did you read what Tim wrote? He pointed out that you are only
answering one half of the question that needs answering, and it's by
far the easier half. Yes, it's relatively easy to check if each
package in a proposed update push is installable. What's much harder
is to check whether pushing that packages makes *any other package in
the distribution* non-installable.
If you send an update that bumps the soname of a library, for
instance, *that update itself* won't fail a depcheck which just checks
if that package can be installed. You somehow need your depcheck to
know to try and install various packages that depend on your update
and see if *they* work OK.
(The question of what package is 'to blame' for a dependency issue is
not always entirely straightforward, either; it's not always quite as
simple as 'take the apparently-offending update out').
It's hard to see how you build a perfect dep check other than trying
to solve the deps of *every single package in the distro* against
every proposed update.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
1:47 a.m.
Le dimanche 12 avril 2015 à 17:06 -0700, Adam Williamson a écrit :
It's hard to see how you build a perfect dep check other than trying
to solve the deps of *every single package in the distro* against
every proposed update.
Can't we run repoclosure on (at the same time) the fedora repo, the
updates repo, and a temporary repo made of the packages to be pushed?
Repoclosure does check for the deps of every single package in the set
of repos it is provided.
--
Mathieu
12:43 p.m.
On Mon, 2015-04-13 at 08:47 +0200, Mathieu Bridon wrote:
Le dimanche 12 avril 2015 à 17:06 -0700, Adam Williamson a écrit :
>
> It's hard to see how you build a perfect dep check other than
> trying
> to solve the deps of *every single package in the distro* against
> every proposed update.
Can't we run repoclosure on (at the same time) the fedora repo, the
updates repo, and a temporary repo made of the packages to be pushed?
Repoclosure does check for the deps of every single package in the
set
of repos it is provided.
Not sure offhand if we've looked into using repoclosure to check this,
but one obvious issue I can think of is, what if repoclosure isn't
clean *to start with*? Do you diff the outputs and try to decide
whether things got better or worse? And what exactly do you do when
decide things got worse? Parse the repoclosure and try to guess which
of the updates to blame? That's already complex enough, I guess, that
we can't expect it to be 100%.
I hope this discussion is illustrating that my initial point was
accurate: any proposal which relies on the existence of a 100%
reliable depcheck is a problematic proposal. :)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
1:01 p.m.
On Mon, 2015-04-13 at 10:43 -0700, Adam Williamson wrote:
On Mon, 2015-04-13 at 08:47 +0200, Mathieu Bridon wrote:
> Le dimanche 12 avril 2015 à 17:06 -0700, Adam Williamson a écrit :
> >
> > It's hard to see how you build a perfect dep check other than
> > trying
> > to solve the deps of *every single package in the distro* against
> > every proposed update.
>
> Can't we run repoclosure on (at the same time) the fedora repo, the
> updates repo, and a temporary repo made of the packages to be pushed?
>
> Repoclosure does check for the deps of every single package in the
> set
> of repos it is provided.
Not sure offhand if we've looked into using repoclosure to check this,
but one obvious issue I can think of is, what if repoclosure isn't
clean *to start with*?
Block all updates push until repoclosure gets cleaned?
Of course, Bodhi admins would need to still be able to force pushes, to
not block security updates or updates which fix repoclosure.
Think of the incentive this would provide to fix broken deps! :)
--
Mathieu
7:33 a.m.
On 8. 4. 2015 at 11:05:20, drago01 wrote:
On Tue, Apr 7, 2015 at 6:37 PM, Adam Williamson
<adamwill(a)fedoraproject.org> wrote:
> On Tue, 2015-04-07 at 18:33 +0200, drago01 wrote:
>> On Tue, Apr 7, 2015 at 6:00 PM, Reindl Harald <h.reindl(a)thelounge.net
>>
>> > wrote:
>> >
>> > Am 07.04.2015 um 17:53 schrieb Ralf Corsepius:
>> > > On 04/07/2015 05:07 PM, Kevin Fenzi wrote:
>> > > > dnf's default behavior is like yum with --skip-broken
already.
>> > >
>> > > WHAT?
>> > >
>> > > --skip-broken is a band-aid to work around packaging mistakes
>> > > and bugs
>> > > and NOT be the default.
>> > >
>> > > IMO, this kind of behavior is not helpful and therefore should
>> > > be reverted
>> >
>> > +1
>> >
>> > that's unacceptable and leads in burry *real* problems resulting
>> > in sonner
>> > or later security updates are broken and nobody take snotice soon
>> > enough
>>
>> The bug is elsewhere though ... i.e. that is even possible to push
>> updates with broken deps.
>> Rawhide is a different story but everything that goes through bodhi
>> (stable releases and branched) should simply refuse pushes with
>> broken
>> deps.
>
> This is easier said than done. We don't have a perfect dependency
> checker and it's not at all easy to write one. tflink and John Dulaney
> have more details if you're interested, but yes, this is not a trivial
> thing we can just wave a wand and make happen.
We do have dep solvers otherwise no one would notice that a dep is
broken ever. (like libsolv + hawkey).
So what bodhi should do is to ask "has this package all dependencies
satisfied with base + updates + other packages in this push" for every
package in the push.
If the answer is "no" for a package cancel the push; remove it;
restart and only push the once that has satisfied deps.
Report the failed once to the maintainers so that they can fix it.
For the record, we are in touch with Fedora QA team about this and we will be
helping them with improving the dependency checks.
Thanks
Jan
1:41 a.m.
On 7. 4. 2015 at 17:53:42, Ralf Corsepius wrote:
On 04/07/2015 05:07 PM, Kevin Fenzi wrote:
> On Tue, 7 Apr 2015 08:38:57 -0500
>
> Bruno Wolff III <bruno(a)wolff.to> wrote:
>> On Tue, Apr 07, 2015 at 10:22:25 -0300,
>>
>> Paulo César Pereira de Andrade
>>
>> <paulo.cesar.pereira.de.andrade(a)gmail.com> wrote:
>>> I had also switched back to yum in rawhide due to --skip-broken,
>>>
>>> and
>>> in a few updates not even needing it (I would first see what is
>>> broken, and if not something "vital", use --skip-broken), while
dnf
>>> would just fail with cryptic messages. I can keep up if kde or gnome
>>> is broken, or some other stuff that does not prevent boot and a
>>> functional system.
>>
>> dnf really does need --skip-broken like support if it is to replace
>> yum. yum can be a lot faster than the needed work around to get dnf
>> to work equivalently. I am considering going back to yum in rawhide
>> rather than continuig to test dnf in rawhide because of this issue.
>
> dnf's default behavior is like yum with --skip-broken already.
WHAT?
--skip-broken is a band-aid to work around packaging mistakes and bugs
and NOT be the default.
IMO, this kind of behavior is not helpful and therefore should be reverted.
This behavior is actually helpful, as it doesn't bother users with a bunch of
broken deps messages they usually don't fully understand (check out how many
of these bugs were filed against yum over the years).
Putting the opinion of myself and the dnf team aside, I'd like to point out
that the information you want is still available - dnf check-update will show
you all the updates, even those that have broken deps. Running this command
right after dnf upgrade will list you those that could not be installed.
Thanks
Jan
3:24 a.m.
Dne 8.4.2015 v 08:41 Jan Zelený napsal(a):
On 7. 4. 2015 at 17:53:42, Ralf Corsepius wrote:
> On 04/07/2015 05:07 PM, Kevin Fenzi wrote:
>> On Tue, 7 Apr 2015 08:38:57 -0500
>>
>> Bruno Wolff III <bruno(a)wolff.to> wrote:
>>> On Tue, Apr 07, 2015 at 10:22:25 -0300,
>>>
>>> Paulo César Pereira de Andrade
>>>
>>> <paulo.cesar.pereira.de.andrade(a)gmail.com> wrote:
>>>> I had also switched back to yum in rawhide due to --skip-broken,
>>>>
>>>> and
>>>> in a few updates not even needing it (I would first see what is
>>>> broken, and if not something "vital", use --skip-broken), while
dnf
>>>> would just fail with cryptic messages. I can keep up if kde or gnome
>>>> is broken, or some other stuff that does not prevent boot and a
>>>> functional system.
>>> dnf really does need --skip-broken like support if it is to replace
>>> yum. yum can be a lot faster than the needed work around to get dnf
>>> to work equivalently. I am considering going back to yum in rawhide
>>> rather than continuig to test dnf in rawhide because of this issue.
>> dnf's default behavior is like yum with --skip-broken already.
> WHAT?
>
> --skip-broken is a band-aid to work around packaging mistakes and bugs
> and NOT be the default.
>
> IMO, this kind of behavior is not helpful and therefore should be reverted.
This behavior is actually helpful, as it doesn't bother users with a bunch of
broken deps messages they usually don't fully understand (check out how many
of these bugs were filed against yum over the years).
Putting the opinion of myself and the dnf team aside, I'd like to point out
that the information you want is still available - dnf check-update will show
you all the updates, even those that have broken deps. Running this command
right after dnf upgrade will list you those that could not be installed.
Thanks
Jan
Is there chance to have --skip-broken enabled/disabled for certain
repositories? For example, you probably want to use --skip-broken for
"updates", while you don't want to use it for "updates-testing"
or
"rawhide", since in there repositories, the bugs should be caught and
removed.
Vít
3:26 a.m.
Am 08.04.2015 um 08:41 schrieb Jan Zelený:
On 7. 4. 2015 at 17:53:42, Ralf Corsepius wrote:
> On 04/07/2015 05:07 PM, Kevin Fenzi wrote:
>> On Tue, 7 Apr 2015 08:38:57 -0500
>>
>> Bruno Wolff III <bruno(a)wolff.to> wrote:
>>> On Tue, Apr 07, 2015 at 10:22:25 -0300,
>>>
>>> Paulo César Pereira de Andrade
>>>
>>> <paulo.cesar.pereira.de.andrade(a)gmail.com> wrote:
>>>> I had also switched back to yum in rawhide due to --skip-broken,
>>>>
>>>> and
>>>> in a few updates not even needing it (I would first see what is
>>>> broken, and if not something "vital", use --skip-broken), while
dnf
>>>> would just fail with cryptic messages. I can keep up if kde or gnome
>>>> is broken, or some other stuff that does not prevent boot and a
>>>> functional system.
>>>
>>> dnf really does need --skip-broken like support if it is to replace
>>> yum. yum can be a lot faster than the needed work around to get dnf
>>> to work equivalently. I am considering going back to yum in rawhide
>>> rather than continuig to test dnf in rawhide because of this issue.
>>
>> dnf's default behavior is like yum with --skip-broken already.
>
> WHAT?
>
> --skip-broken is a band-aid to work around packaging mistakes and bugs
> and NOT be the default.
>
> IMO, this kind of behavior is not helpful and therefore should be reverted.
This behavior is actually helpful, as it doesn't bother users with a bunch of
broken deps messages they usually don't fully understand (check out how many
of these bugs were filed against yum over the years).
well, check out how many bugs where filed for the correct component
that default don't solve any problem, it's just put the head in the sand
and burry it
Putting the opinion of myself and the dnf team aside, I'd like to
point out
that the information you want is still available - dnf check-update will show
you all the updates, even those that have broken deps. Running this command
right after dnf upgrade will list you those that could not be installed
the world don't work that way
*nobody* even not myself would call "dnf check-update" after "dnf
upgrade" installed updates and did not complain about anything
7:39 a.m.
On 8. 4. 2015 at 10:26:51, Reindl Harald wrote:
Am 08.04.2015 um 08:41 schrieb Jan Zelený:
> On 7. 4. 2015 at 17:53:42, Ralf Corsepius wrote:
>> On 04/07/2015 05:07 PM, Kevin Fenzi wrote:
>>> On Tue, 7 Apr 2015 08:38:57 -0500
>>>
>>> Bruno Wolff III <bruno(a)wolff.to> wrote:
>>>> On Tue, Apr 07, 2015 at 10:22:25 -0300,
>>>>
>>>> Paulo César Pereira de Andrade
>>>>
>>>> <paulo.cesar.pereira.de.andrade(a)gmail.com> wrote:
>>>>> I had also switched back to yum in rawhide due to --skip-broken,
>>>>>
>>>>> and
>>>>> in a few updates not even needing it (I would first see what is
>>>>> broken, and if not something "vital", use --skip-broken),
while dnf
>>>>> would just fail with cryptic messages. I can keep up if kde or
gnome
>>>>> is broken, or some other stuff that does not prevent boot and a
>>>>> functional system.
>>>>
>>>> dnf really does need --skip-broken like support if it is to replace
>>>> yum. yum can be a lot faster than the needed work around to get dnf
>>>> to work equivalently. I am considering going back to yum in rawhide
>>>> rather than continuig to test dnf in rawhide because of this issue.
>>>
>>> dnf's default behavior is like yum with --skip-broken already.
>>
>> WHAT?
>>
>> --skip-broken is a band-aid to work around packaging mistakes and bugs
>> and NOT be the default.
>>
>> IMO, this kind of behavior is not helpful and therefore should be
>> reverted.
>
> This behavior is actually helpful, as it doesn't bother users with a bunch
> of broken deps messages they usually don't fully understand (check out
> how many of these bugs were filed against yum over the years).
well, check out how many bugs where filed for the correct component
that default don't solve any problem, it's just put the head in the sand
and burry it
> Putting the opinion of myself and the dnf team aside, I'd like to point
> out
> that the information you want is still available - dnf check-update will
> show you all the updates, even those that have broken deps. Running this
> command right after dnf upgrade will list you those that could not be
> installed
the world don't work that way
*nobody* even not myself would call "dnf check-update" after "dnf
upgrade" installed updates and did not complain about anything
You are right, people use it the other way - we have had reports stating that
dnf check-update shows packages that dnf upgrade doesn't select. In other
words, the information about broken updates is still available to the user.
Thanks
Jan
7:44 a.m.
Am 08.04.2015 um 14:39 schrieb Jan Zelený:
On 8. 4. 2015 at 10:26:51, Reindl Harald wrote:
> Am 08.04.2015 um 08:41 schrieb Jan Zelený:
>> Putting the opinion of myself and the dnf team aside, I'd like to point
>> out
>> that the information you want is still available - dnf check-update will
>> show you all the updates, even those that have broken deps. Running this
>> command right after dnf upgrade will list you those that could not be
>> installed
> the world don't work that way
>
> *nobody* even not myself would call "dnf check-update" after "dnf
> upgrade" installed updates and did not complain about anything
You are right, people use it the other way - we have had reports stating that
dnf check-update shows packages that dnf upgrade doesn't select. In other
words, the information about broken updates is still available to the user
your repsonse is completly unclear
"you are right", "people use it the other way", "updates is still
available to the user" in combination makes no sense at all
to make it clear: a in theory available option is worhless and just
because you had reports of people using "dnf check-update" don't mean
"people in general use it that way"
i am pretty sure most people just use "yum upgrade" and that's it and i
can't imagine why i should type "dnf check-update" at all when "yum
upgrade" is supposed to give the same answer and finally needs just "y"
for install them if available
10:36 a.m.
On 04/08/2015 08:39 AM, Jan Zelený wrote:
On 8. 4. 2015 at 10:26:51, Reindl Harald wrote:
> Am 08.04.2015 um 08:41 schrieb Jan Zelený:
>
>> Putting the opinion of myself and the dnf team aside, I'd like to point
>> out
>> that the information you want is still available - dnf check-update will
>> show you all the updates, even those that have broken deps. Running this
>> command right after dnf upgrade will list you those that could not be
>> installed
> the world don't work that way
>
> *nobody* even not myself would call "dnf check-update" after "dnf
> upgrade" installed updates and did not complain about anything
You are right, people use it the other way - we have had reports stating that
dnf check-update shows packages that dnf upgrade doesn't select. In other
words, the information about broken updates is still available to the user.
Perhaps dnf should keep track whether it had to 'skip-broken' , and
report packages that were skipped during the update?
I agree with Harald that invoking it quietly is the wrong thing to do. I
have an extensive set of repositories (Fedora, Fusion, local, src/debug)
and I had to "yum --skip-broken" disturbingly often.
1:53 a.m.
On 8.4.2015 17:36, Przemek Klosowski wrote:
On 04/08/2015 08:39 AM, Jan Zelený wrote:
> On 8. 4. 2015 at 10:26:51, Reindl Harald wrote:
>> Am 08.04.2015 um 08:41 schrieb Jan Zelený:
>>
>>> Putting the opinion of myself and the dnf team aside, I'd like to point
>>> out
>>> that the information you want is still available - dnf check-update will
>>> show you all the updates, even those that have broken deps. Running this
>>> command right after dnf upgrade will list you those that could not be
>>> installed
>> the world don't work that way
>>
>> *nobody* even not myself would call "dnf check-update" after "dnf
>> upgrade" installed updates and did not complain about anything
> You are right, people use it the other way - we have had reports stating that
> dnf check-update shows packages that dnf upgrade doesn't select. In other
> words, the information about broken updates is still available to the user.
>
Perhaps dnf should keep track whether it had to 'skip-broken' , and report
packages that were skipped during the update?
I very much agree with this. As a user, I expect that 'dnf upgrade' will give
me latest packages and that DNF will tell me the fact that newer packages are
available but not installable.
Maybe it could have a form of plugin, at least for the beginning?
I agree with Harald that invoking it quietly is the wrong thing to
do. I have
an extensive set of repositories (Fedora, Fusion, local, src/debug) and I had
to "yum --skip-broken" disturbingly often.
--
Petr Spacek @ Red Hat
2:18 a.m.
On 10. 4. 2015 at 08:53:46, Petr Spacek wrote:
On 8.4.2015 17:36, Przemek Klosowski wrote:
> On 04/08/2015 08:39 AM, Jan Zelený wrote:
>> On 8. 4. 2015 at 10:26:51, Reindl Harald wrote:
>>> Am 08.04.2015 um 08:41 schrieb Jan Zelený:
>>>> Putting the opinion of myself and the dnf team aside, I'd like to
point
>>>> out
>>>> that the information you want is still available - dnf check-update
>>>> will
>>>> show you all the updates, even those that have broken deps. Running
>>>> this
>>>> command right after dnf upgrade will list you those that could not be
>>>> installed
>>>
>>> the world don't work that way
>>>
>>> *nobody* even not myself would call "dnf check-update" after
"dnf
>>> upgrade" installed updates and did not complain about anything
>>
>> You are right, people use it the other way - we have had reports stating
>> that dnf check-update shows packages that dnf upgrade doesn't select. In
>> other words, the information about broken updates is still available to
>> the user.>
> Perhaps dnf should keep track whether it had to 'skip-broken' , and report
> packages that were skipped during the update?
I very much agree with this. As a user, I expect that 'dnf upgrade' will
give me latest packages and that DNF will tell me the fact that newer
packages are available but not installable.
Maybe it could have a form of plugin, at least for the beginning?
Again, dnf check-update already does that. While I understand the request to
make it more convenient, I can't promise you that we will do that. Please try
to understand, we try to keep dnf as structurally clean as possible and
duplicating functionality does not help that.
Thanks
Jan
2:22 a.m.
On 10.4.2015 09:18, Jan Zelený wrote:
On 10. 4. 2015 at 08:53:46, Petr Spacek wrote:
> On 8.4.2015 17:36, Przemek Klosowski wrote:
>> On 04/08/2015 08:39 AM, Jan Zelený wrote:
>>> On 8. 4. 2015 at 10:26:51, Reindl Harald wrote:
>>>> Am 08.04.2015 um 08:41 schrieb Jan Zelený:
>>>>> Putting the opinion of myself and the dnf team aside, I'd like to
point
>>>>> out
>>>>> that the information you want is still available - dnf check-update
>>>>> will
>>>>> show you all the updates, even those that have broken deps. Running
>>>>> this
>>>>> command right after dnf upgrade will list you those that could not
be
>>>>> installed
>>>>
>>>> the world don't work that way
>>>>
>>>> *nobody* even not myself would call "dnf check-update" after
"dnf
>>>> upgrade" installed updates and did not complain about anything
>>>
>>> You are right, people use it the other way - we have had reports stating
>>> that dnf check-update shows packages that dnf upgrade doesn't select. In
>>> other words, the information about broken updates is still available to
>>> the user.>
>> Perhaps dnf should keep track whether it had to 'skip-broken' , and
report
>> packages that were skipped during the update?
>
> I very much agree with this. As a user, I expect that 'dnf upgrade' will
> give me latest packages and that DNF will tell me the fact that newer
> packages are available but not installable.
>
> Maybe it could have a form of plugin, at least for the beginning?
Again, dnf check-update already does that. While I understand the request to
make it more convenient, I can't promise you that we will do that. Please try
to understand, we try to keep dnf as structurally clean as possible and
duplicating functionality does not help that.
I was thinking more about a plugin which calls 'check-update' automatically
when 'upgrade' command finishes.
--
Petr^2 Spacek
2:34 a.m.
Am 10.04.2015 um 09:18 schrieb Jan Zelený:
On 10. 4. 2015 at 08:53:46, Petr Spacek wrote:
> I very much agree with this. As a user, I expect that 'dnf upgrade' will
> give me latest packages and that DNF will tell me the fact that newer
> packages are available but not installable.
>
> Maybe it could have a form of plugin, at least for the beginning?
Again, dnf check-update already does that
Again: that argument is pointless because *nobody* is calling it by hand
after "dnf upgrade" and so that information is *not* available for the
regular dnf/yum user
6:04 a.m.
On 10. 4. 2015 at 09:34:15, Reindl Harald wrote:
Am 10.04.2015 um 09:18 schrieb Jan Zelený:
> On 10. 4. 2015 at 08:53:46, Petr Spacek wrote:
>> I very much agree with this. As a user, I expect that 'dnf upgrade'
will
>> give me latest packages and that DNF will tell me the fact that newer
>> packages are available but not installable.
>>
>> Maybe it could have a form of plugin, at least for the beginning?
>
> Again, dnf check-update already does that
Again: that argument is pointless because *nobody* is calling it by hand
after "dnf upgrade" and so that information is *not* available for the
regular dnf/yum user
The vision for dnf is to be more simple and more effective tool for admins that
will not try to solve problems of other components. On the other hand we want
to enable package maintainers and other advanced users to achieve their use
cases somehow but dnf will never be a debugging tool. Bottom line, we will
consider this feature request but considering it is the only promise I can
give you.
Thanks
Jan
6:16 a.m.
On 04/10/2015 07:04 AM, Jan Zelený wrote:
On 10. 4. 2015 at 09:34:15, Reindl Harald wrote:
> Am 10.04.2015 um 09:18 schrieb Jan Zelený:
>> On 10. 4. 2015 at 08:53:46, Petr Spacek wrote:
>>> I very much agree with this. As a user, I expect that 'dnf upgrade'
will
>>> give me latest packages and that DNF will tell me the fact that newer
>>> packages are available but not installable.
>>>
>>> Maybe it could have a form of plugin, at least for the beginning?
>> Again, dnf check-update already does that
> Again: that argument is pointless because *nobody* is calling it by hand
> after "dnf upgrade" and so that information is *not* available for the
> regular dnf/yum user
The vision for dnf is to be more simple and more effective tool for admins that
will not try to solve problems of other components. On the other hand we want
to enable package maintainers and other advanced users to achieve their use
cases somehow but dnf will never be a debugging tool. Bottom line, we will
consider this feature request but considering it is the only promise I can
give you.
Thanks
Jan
Mr. Zeleny,
As an admin and user how does this behavior make it simpler for me? I now have to do 2
steps to make sure things
worked as expected. How is this simpler?
Regards,
--
Stephen Clark
*NetWolves Managed Services, LLC.*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.clark(a)netwolves.com
http://www.netwolves.com
7:40 a.m.
On 10. 4. 2015 at 07:16:30, Steve Clark wrote:
On 04/10/2015 07:04 AM, Jan Zelený wrote:
> On 10. 4. 2015 at 09:34:15, Reindl Harald wrote:
>> Am 10.04.2015 um 09:18 schrieb Jan Zelený:
>>> On 10. 4. 2015 at 08:53:46, Petr Spacek wrote:
>>>> I very much agree with this. As a user, I expect that 'dnf
upgrade'
>>>> will
>>>> give me latest packages and that DNF will tell me the fact that newer
>>>> packages are available but not installable.
>>>>
>>>> Maybe it could have a form of plugin, at least for the beginning?
>>>
>>> Again, dnf check-update already does that
>>
>> Again: that argument is pointless because *nobody* is calling it by hand
>> after "dnf upgrade" and so that information is *not* available for
the
>> regular dnf/yum user
>
> The vision for dnf is to be more simple and more effective tool for admins
> that will not try to solve problems of other components. On the other
> hand we want to enable package maintainers and other advanced users to
> achieve their use cases somehow but dnf will never be a debugging tool.
> Bottom line, we will consider this feature request but considering it is
> the only promise I can give you.
>
> Thanks
> Jan
Mr. Zeleny,
As an admin and user how does this behavior make it simpler for me? I now
have to do 2 steps to make sure things worked as expected. How is this
simpler?
What we envision is for the admin not to debug the problem himself, it's not
his responsibility. Packaging problems should be discovered automatically when
an update is created. This is being worked on by Fedora QA IIUIC. Package
maintainers are the second line of defense, as they should resolve these
problems before updates go stable. But these issues should never get to the
end user.
Bottom line, if an update is in a repo but it's not installable, it's
technically not available to the client as some of the bits are obviously
missing. Maybe you could help me understand what value does the information
have for you when you can't install the packages anyway.
Thanks
Jan
7:56 a.m.
On 04/10/2015 08:40 AM, Jan Zelený wrote:
On 10. 4. 2015 at 07:16:30, Steve Clark wrote:
> On 04/10/2015 07:04 AM, Jan Zelený wrote:
>> On 10. 4. 2015 at 09:34:15, Reindl Harald wrote:
>>> Am 10.04.2015 um 09:18 schrieb Jan Zelený:
>>>> On 10. 4. 2015 at 08:53:46, Petr Spacek wrote:
>>>>> I very much agree with this. As a user, I expect that 'dnf
upgrade'
>>>>> will
>>>>> give me latest packages and that DNF will tell me the fact that
newer
>>>>> packages are available but not installable.
>>>>>
>>>>> Maybe it could have a form of plugin, at least for the beginning?
>>>> Again, dnf check-update already does that
>>> Again: that argument is pointless because *nobody* is calling it by hand
>>> after "dnf upgrade" and so that information is *not* available for
the
>>> regular dnf/yum user
>> The vision for dnf is to be more simple and more effective tool for admins
>> that will not try to solve problems of other components. On the other
>> hand we want to enable package maintainers and other advanced users to
>> achieve their use cases somehow but dnf will never be a debugging tool.
>> Bottom line, we will consider this feature request but considering it is
>> the only promise I can give you.
>>
>> Thanks
>> Jan
> Mr. Zeleny,
>
> As an admin and user how does this behavior make it simpler for me? I now
> have to do 2 steps to make sure things worked as expected. How is this
> simpler?
What we envision is for the admin not to debug the problem himself, it's not
his responsibility. Packaging problems should be discovered automatically when
an update is created. This is being worked on by Fedora QA IIUIC. Package
maintainers are the second line of defense, as they should resolve these
problems before updates go stable. But these issues should never get to the
end user.
Bottom line, if an update is in a repo but it's not installable, it's
technically not available to the client as some of the bits are obviously
missing. Maybe you could help me understand what value does the information
have for you when you can't install the packages anyway.
Thanks
Jan
Mr. Zeleny,
It is naive, in my opinion, to assume that Fedora is going to supply all the packages one
might need. I quite frequently run into
the problem of dependencies from other repos clashing with Fedora's, and others and
have to use the information provided
by yum to determine how to clean things up. In what is proposed now I will have to do two
steps to determine there is a problem.
Regards,
--
Stephen Clark
*NetWolves Managed Services, LLC.*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.clark(a)netwolves.com
http://www.netwolves.com
8:06 a.m.
On 10/04/15 13:40, Jan Zelený wrote:
What we envision is for the admin not to debug the problem himself,
it's not
his responsibility. Packaging problems should be discovered automatically when
an update is created. This is being worked on by Fedora QA IIUIC. Package
maintainers are the second line of defense, as they should resolve these
problems before updates go stable. But these issues should never get to the
end user.
The problem is this magical future world where packagers can't push an
update that breaks things is just a pipe dream currently.
Right now the way packagers find out that somebody has broken a
dependency is when yum barfs on an update. I had it happen just this
week when somebody pushed a new major version of mozilla-fira-fonts in
F21 that broke the dependencies in one of my packages.
Of course yum told me that and I was able to push an update for my
package within about 24 hours of the breakage occurring.
In a dnf world I would have been none the wiser as things stand.
Personally I think doing what yum does with --skip-broken, where it does
the update but tells you it had to skip some things, is probably the
best compromise as a default, at least until the magic software gnomes
create the future world where broken updates can't happen.
Tom
--
Tom Hughes (tom(a)compton.nu)
http://compton.nu/
8:09 a.m.
Am 10.04.2015 um 14:40 schrieb Jan Zelený:
On 10. 4. 2015 at 07:16:30, Steve Clark wrote:
> As an admin and user how does this behavior make it simpler for me? I now
> have to do 2 steps to make sure things worked as expected. How is this
> simpler?
What we envision is for the admin not to debug the problem himself, it's not
his responsibility. Packaging problems should be discovered automatically when
an update is created. This is being worked on by Fedora QA IIUIC. Package
maintainers are the second line of defense, as they should resolve these
problems before updates go stable. But these issues should never get to the
end user
that's all complelty wrong because the ordinary enduser is not using
yum/dnf but some graphical tool - so the endusers you are talking about
are advanced users and don't expect problems burried
8:15 a.m.
On 10. 4. 2015 at 08:56:16, Steve Clark wrote:
On 04/10/2015 08:40 AM, Jan Zelený wrote:
> On 10. 4. 2015 at 07:16:30, Steve Clark wrote:
>> On 04/10/2015 07:04 AM, Jan Zelený wrote:
>>> On 10. 4. 2015 at 09:34:15, Reindl Harald wrote:
>>>> Am 10.04.2015 um 09:18 schrieb Jan Zelený:
>>>>> On 10. 4. 2015 at 08:53:46, Petr Spacek wrote:
>>>>>> I very much agree with this. As a user, I expect that 'dnf
upgrade'
>>>>>> will
>>>>>> give me latest packages and that DNF will tell me the fact that
newer
>>>>>> packages are available but not installable.
>>>>>>
>>>>>> Maybe it could have a form of plugin, at least for the
beginning?
>>>>>
>>>>> Again, dnf check-update already does that
>>>>
>>>> Again: that argument is pointless because *nobody* is calling it by
>>>> hand
>>>> after "dnf upgrade" and so that information is *not* available
for the
>>>> regular dnf/yum user
>>>
>>> The vision for dnf is to be more simple and more effective tool for
>>> admins
>>> that will not try to solve problems of other components. On the other
>>> hand we want to enable package maintainers and other advanced users to
>>> achieve their use cases somehow but dnf will never be a debugging tool.
>>> Bottom line, we will consider this feature request but considering it is
>>> the only promise I can give you.
>>>
>>> Thanks
>>> Jan
>>
>> Mr. Zeleny,
>>
>> As an admin and user how does this behavior make it simpler for me? I now
>> have to do 2 steps to make sure things worked as expected. How is this
>> simpler?
>
> What we envision is for the admin not to debug the problem himself, it's
> not his responsibility. Packaging problems should be discovered
> automatically when an update is created. This is being worked on by
> Fedora QA IIUIC. Package maintainers are the second line of defense, as
> they should resolve these problems before updates go stable. But these
> issues should never get to the end user.
>
> Bottom line, if an update is in a repo but it's not installable, it's
> technically not available to the client as some of the bits are obviously
> missing. Maybe you could help me understand what value does the
> information
> have for you when you can't install the packages anyway.
>
> Thanks
> Jan
Mr. Zeleny,
It is naive, in my opinion, to assume that Fedora is going to supply all the
packages one might need. I quite frequently run into the problem of
dependencies from other repos clashing with Fedora's, and others and have
to use the information provided by yum to determine how to clean things up.
In what is proposed now I will have to do two steps to determine there is a
problem.
Ok, I think I understand your problem a little better now, even though I still
maintain the opinion that dnf should not be a debugging tool. I have seen a
few proposals here that have the potential to be a nice compromise.
Also I wonder if dnf check-update is actually useful. From what I've read
here, it seems it's barely used. If dnf is to have its functionality covered
by the upgrade command, perhaps it's possible to remove the check-update
command.
Thanks
Jan
8:32 a.m.
Am 10.04.2015 um 15:15 schrieb Jan Zelený:
> It is naive, in my opinion, to assume that Fedora is going to
supply all the
> packages one might need. I quite frequently run into the problem of
> dependencies from other repos clashing with Fedora's, and others and have
> to use the information provided by yum to determine how to clean things up.
> In what is proposed now I will have to do two steps to determine there is a
> problem.
Ok, I think I understand your problem a little better now, even though I still
maintain the opinion that dnf should not be a debugging tool. I have seen a
few proposals here that have the potential to be a nice compromise.
Also I wonder if dnf check-update is actually useful. From what I've read
here, it seems it's barely used. If dnf is to have its functionality covered
by the upgrade command, perhaps it's possible to remove the check-update
command
we use "yum check-update" regulary once per day on the admin server to
check for available security updates in "updates-testing" and report the
available ones via cron mail
that's prodcution, on developer and admin workstations "yum upgrade" is
enough
#!/usr/bin/bash
yum_output=`LANG=C; yum --enablerepo=updates-testing -q check-update
--security 2> /dev/null`
echo $yum_output | xargs | sed 's/ updates//g' | tr -d '\n'
9:02 a.m.
----- Original Message -----
From: "Jan Zelený" <jzeleny(a)redhat.com>
To: "Steve Clark" <sclark(a)netwolves.com>
Cc: devel(a)lists.fedoraproject.org
Sent: Friday, April 10, 2015 3:15:42 PM
Subject: Re: dnf replacing yum and dnf-yum
On 10. 4. 2015 at 08:56:16, Steve Clark wrote:
> On 04/10/2015 08:40 AM, Jan Zelený wrote:
> > On 10. 4. 2015 at 07:16:30, Steve Clark wrote:
> >> On 04/10/2015 07:04 AM, Jan Zelený wrote:
> >>> On 10. 4. 2015 at 09:34:15, Reindl Harald wrote:
> >>>> Am 10.04.2015 um 09:18 schrieb Jan Zelený:
> >>>>> On 10. 4. 2015 at 08:53:46, Petr Spacek wrote:
> >>>>>> I very much agree with this. As a user, I expect that
'dnf upgrade'
> >>>>>> will
> >>>>>> give me latest packages and that DNF will tell me the fact
that
> >>>>>> newer
> >>>>>> packages are available but not installable.
> >>>>>>
> >>>>>> Maybe it could have a form of plugin, at least for the
beginning?
> >>>>>
> >>>>> Again, dnf check-update already does that
> >>>>
> >>>> Again: that argument is pointless because *nobody* is calling it
by
> >>>> hand
> >>>> after "dnf upgrade" and so that information is *not*
available for the
> >>>> regular dnf/yum user
> >>>
> >>> The vision for dnf is to be more simple and more effective tool for
> >>> admins
> >>> that will not try to solve problems of other components. On the other
> >>> hand we want to enable package maintainers and other advanced users to
> >>> achieve their use cases somehow but dnf will never be a debugging
tool.
> >>> Bottom line, we will consider this feature request but considering it
> >>> is
> >>> the only promise I can give you.
> >>>
> >>> Thanks
> >>> Jan
> >>
> >> Mr. Zeleny,
> >>
> >> As an admin and user how does this behavior make it simpler for me? I
> >> now
> >> have to do 2 steps to make sure things worked as expected. How is this
> >> simpler?
> >
> > What we envision is for the admin not to debug the problem himself, it's
> > not his responsibility. Packaging problems should be discovered
> > automatically when an update is created. This is being worked on by
> > Fedora QA IIUIC. Package maintainers are the second line of defense, as
> > they should resolve these problems before updates go stable. But these
> > issues should never get to the end user.
> >
> > Bottom line, if an update is in a repo but it's not installable, it's
> > technically not available to the client as some of the bits are obviously
> > missing. Maybe you could help me understand what value does the
> > information
> > have for you when you can't install the packages anyway.
> >
> > Thanks
> > Jan
>
> Mr. Zeleny,
>
> It is naive, in my opinion, to assume that Fedora is going to supply all
> the
> packages one might need. I quite frequently run into the problem of
> dependencies from other repos clashing with Fedora's, and others and have
> to use the information provided by yum to determine how to clean things up.
> In what is proposed now I will have to do two steps to determine there is a
> problem.
Ok, I think I understand your problem a little better now, even though I
still
maintain the opinion that dnf should not be a debugging tool. I have seen a
few proposals here that have the potential to be a nice compromise.
Also I wonder if dnf check-update is actually useful. From what I've read
here, it seems it's barely used. If dnf is to have its functionality covered
by the upgrade command, perhaps it's possible to remove the check-update
command.
FYI, at first sight, the implementation of "dnf check-update" is almost the same
as "dnf list upgrades" except that "check-update" returns a special
exit code...
--
Radek Holý
Associate Software Engineer
Software Management Team
Red Hat Czech
9:10 a.m.
----- Original Message -----
From: "Radek Holy" <rholy(a)redhat.com>
To: "Development discussions related to Fedora"
<devel(a)lists.fedoraproject.org>
Sent: Friday, April 10, 2015 4:02:12 PM
Subject: Re: dnf replacing yum and dnf-yum
----- Original Message -----
> From: "Jan Zelený" <jzeleny(a)redhat.com>
> To: "Steve Clark" <sclark(a)netwolves.com>
> Cc: devel(a)lists.fedoraproject.org
> Sent: Friday, April 10, 2015 3:15:42 PM
> Subject: Re: dnf replacing yum and dnf-yum
>
> On 10. 4. 2015 at 08:56:16, Steve Clark wrote:
> > On 04/10/2015 08:40 AM, Jan Zelený wrote:
> > > On 10. 4. 2015 at 07:16:30, Steve Clark wrote:
> > >> On 04/10/2015 07:04 AM, Jan Zelený wrote:
> > >>> On 10. 4. 2015 at 09:34:15, Reindl Harald wrote:
> > >>>> Am 10.04.2015 um 09:18 schrieb Jan Zelený:
> > >>>>> On 10. 4. 2015 at 08:53:46, Petr Spacek wrote:
> > >>>>>> I very much agree with this. As a user, I expect that
'dnf
> > >>>>>> upgrade'
> > >>>>>> will
> > >>>>>> give me latest packages and that DNF will tell me the
fact that
> > >>>>>> newer
> > >>>>>> packages are available but not installable.
> > >>>>>>
> > >>>>>> Maybe it could have a form of plugin, at least for the
beginning?
> > >>>>>
> > >>>>> Again, dnf check-update already does that
> > >>>>
> > >>>> Again: that argument is pointless because *nobody* is calling
it by
> > >>>> hand
> > >>>> after "dnf upgrade" and so that information is *not*
available for
> > >>>> the
> > >>>> regular dnf/yum user
> > >>>
> > >>> The vision for dnf is to be more simple and more effective tool
for
> > >>> admins
> > >>> that will not try to solve problems of other components. On the
other
> > >>> hand we want to enable package maintainers and other advanced
users
> > >>> to
> > >>> achieve their use cases somehow but dnf will never be a debugging
> > >>> tool.
> > >>> Bottom line, we will consider this feature request but considering
it
> > >>> is
> > >>> the only promise I can give you.
> > >>>
> > >>> Thanks
> > >>> Jan
> > >>
> > >> Mr. Zeleny,
> > >>
> > >> As an admin and user how does this behavior make it simpler for me? I
> > >> now
> > >> have to do 2 steps to make sure things worked as expected. How is
this
> > >> simpler?
> > >
> > > What we envision is for the admin not to debug the problem himself,
> > > it's
> > > not his responsibility. Packaging problems should be discovered
> > > automatically when an update is created. This is being worked on by
> > > Fedora QA IIUIC. Package maintainers are the second line of defense, as
> > > they should resolve these problems before updates go stable. But these
> > > issues should never get to the end user.
> > >
> > > Bottom line, if an update is in a repo but it's not installable,
it's
> > > technically not available to the client as some of the bits are
> > > obviously
> > > missing. Maybe you could help me understand what value does the
> > > information
> > > have for you when you can't install the packages anyway.
> > >
> > > Thanks
> > > Jan
> >
> > Mr. Zeleny,
> >
> > It is naive, in my opinion, to assume that Fedora is going to supply all
> > the
> > packages one might need. I quite frequently run into the problem of
> > dependencies from other repos clashing with Fedora's, and others and have
> > to use the information provided by yum to determine how to clean things
> > up.
> > In what is proposed now I will have to do two steps to determine there is
> > a
> > problem.
>
>
> Ok, I think I understand your problem a little better now, even though I
> still
> maintain the opinion that dnf should not be a debugging tool. I have seen a
> few proposals here that have the potential to be a nice compromise.
>
> Also I wonder if dnf check-update is actually useful. From what I've read
> here, it seems it's barely used. If dnf is to have its functionality
> covered
> by the upgrade command, perhaps it's possible to remove the check-update
> command.
FYI, at first sight, the implementation of "dnf check-update" is almost the
same as "dnf list upgrades" except that "check-update" returns a
special
exit code...
...where the difference is of a questionable value given the discussion above...
--
Radek Holý
Associate Software Engineer
Software Management Team
Red Hat Czech
11:40 a.m.
On Fri, Apr 10, 2015 at 03:15:42PM +0200, Jan Zelený wrote:
On 10. 4. 2015 at 08:56:16, Steve Clark wrote:
> It is naive, in my opinion, to assume that Fedora is going to
supply all the
> packages one might need. I quite frequently run into the problem of
> dependencies from other repos clashing with Fedora's, and others and have
> to use the information provided by yum to determine how to clean things up.
> In what is proposed now I will have to do two steps to determine there is a
> problem.
Ok, I think I understand your problem a little better now, even though I still
maintain the opinion that dnf should not be a debugging tool. I have seen a
few proposals here that have the potential to be a nice compromise.
Another problem can result from someone rebuilding a package locally to
get a newer version. If now a library is updated in an incompatible way
for security reasons, this would break the update. Therefore it is not
just a debugging issue but simply just reporting-that-there-is-a-bug
issue.
Also I wonder if dnf check-update is actually useful. From what
I've read
here, it seems it's barely used. If dnf is to have its functionality covered
by the upgrade command, perhaps it's possible to remove the check-update
command.
Maybe check-update can be changed to just display which updates the
update command would really install instead of just telling which it
might install.
Regards
Till
6:39 a.m.
Hi,
The vision for dnf is to be more simple and more effective tool for
admins that
will not try to solve problems of other components. On the other hand we want
to enable package maintainers and other advanced users to achieve their use
cases somehow but dnf will never be a debugging tool. Bottom line, we will
consider this feature request but considering it is the only promise I can
give you.
How about printing a one-liner along the lines "update skipped $n
packages due to $reason, use $command for details" ?
cheers,
Gerd
6:54 a.m.
Dne 10.4.2015 v 13:04 Jan Zelený napsal(a):
On 10. 4. 2015 at 09:34:15, Reindl Harald wrote:
> Am 10.04.2015 um 09:18 schrieb Jan Zelený:
>> On 10. 4. 2015 at 08:53:46, Petr Spacek wrote:
>>> I very much agree with this. As a user, I expect that 'dnf upgrade'
will
>>> give me latest packages and that DNF will tell me the fact that newer
>>> packages are available but not installable.
>>>
>>> Maybe it could have a form of plugin, at least for the beginning?
>> Again, dnf check-update already does that
> Again: that argument is pointless because *nobody* is calling it by hand
> after "dnf upgrade" and so that information is *not* available for the
> regular dnf/yum user
The vision for dnf is to be more simple and more effective tool for admins that
will not try to solve problems of other components. On the other hand we want
to enable package maintainers and other advanced users to achieve their use
cases somehow but dnf will never be a debugging tool. Bottom line, we will
consider this feature request but considering it is the only promise I can
give you.
Thanks
Jan
To be honest, I never run "check-update" and I will never run it. If I
want to update my system, I run "update", check the list and if there is
nothing worrisome, I proceed. If there is something I dislike in the
list, I quit.
So check-update might be useful for some script, but it is not useful
command for common user. Not mentioning that man page basically says:
"Please note that having a specific newer version available for an
installed package (and reported by check-update) does not imply that
subsequent dnf upgrade will install it. The difference is that dnf
upgrade must also ensure the satisfiability of all dependencies and
other restrictions". In other words, it says it is more or less
unreliable command.
Vít
7:03 a.m.
On Fri, Apr 10, 2015 at 01:54:12PM +0200, Vít Ondruch wrote:
So check-update might be useful for some script, but it is not
useful
command for common user. Not mentioning that man page basically says:
"Please note that having a specific newer version available for an
installed package (and reported by check-update) does not imply that
subsequent dnf upgrade will install it. The difference is that dnf
upgrade must also ensure the satisfiability of all dependencies and
other restrictions". In other words, it says it is more or less
unreliable command.
If you want to reliable force an update to the newest packages,
use 'dnf upgrade --best'.
Cheers,
Michael.
--
Michael Schroeder mls(a)suse.de
SUSE LINUX GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
8:34 a.m.
On 04/10/2015 02:03 PM, Michael Schroeder wrote:
On Fri, Apr 10, 2015 at 01:54:12PM +0200, Vít Ondruch wrote:
> So check-update might be useful for some script, but it is not useful
> command for common user. Not mentioning that man page basically says:
> "Please note that having a specific newer version available for an
> installed package (and reported by check-update) does not imply that
> subsequent dnf upgrade will install it. The difference is that dnf
> upgrade must also ensure the satisfiability of all dependencies and
> other restrictions". In other words, it says it is more or less
> unreliable command.
If you want to reliable force an update to the newest packages,
use 'dnf upgrade --best'.
Except of people, who prefer not receiving updates/bugfixes and want to
live with an outdated system, it's what everybody will want.
Ralf
8:52 a.m.
On 10. 4. 2015 at 15:34:53, Ralf Corsepius wrote:
On 04/10/2015 02:03 PM, Michael Schroeder wrote:
> On Fri, Apr 10, 2015 at 01:54:12PM +0200, Vít Ondruch wrote:
>> So check-update might be useful for some script, but it is not useful
>> command for common user. Not mentioning that man page basically says:
>> "Please note that having a specific newer version available for an
>> installed package (and reported by check-update) does not imply that
>> subsequent dnf upgrade will install it. The difference is that dnf
>> upgrade must also ensure the satisfiability of all dependencies and
>> other restrictions". In other words, it says it is more or less
>> unreliable command.
>
> If you want to reliable force an update to the newest packages,
> use 'dnf upgrade --best'.
Except of people, who prefer not receiving updates/bugfixes and want to
live with an outdated system, it's what everybody will want.
I've been using just `dnf update` to update my system for almost a year now
and there is not a single package on my system that is not updated to the
latest version in the repo.
Thanks
Jan
9:21 a.m.
On Fri, Apr 10, 2015 at 03:52:32PM +0200, Jan Zelený wrote:
I've been using just `dnf update` to update my system for almost
a year now
and there is not a single package on my system that is not updated to the
latest version in the repo.
Hmm, but doesn't that mean that you wouldn't care if '--best' became
the default?
To decide what the default should be you need to look at use cases
where the option makes a difference and then find out, what's best
(or most convenient) for the user.
Cheers,
Michael.
--
Michael Schroeder mls(a)suse.de
SUSE LINUX GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
2:47 a.m.
On 10. 4. 2015 at 16:21:14, Michael Schroeder wrote:
On Fri, Apr 10, 2015 at 03:52:32PM +0200, Jan Zelený wrote:
> I've been using just `dnf update` to update my system for almost a year
> now
> and there is not a single package on my system that is not updated to the
> latest version in the repo.
Hmm, but doesn't that mean that you wouldn't care if '--best' became
the default?
I guess ... I'm trying point out that if you don't need to have every single
update as soon as it's out, both ways will work for you equally well.
To decide what the default should be you need to look at use cases
where the option makes a difference and then find out, what's best
(or most convenient) for the user.
Agreed. I guess I'm just reluctant to change the default at the first sign of
inconvenience. Chances are that the change will be inconvenient to many more
people who are quiet so far because everything works great for them.
Thanks
Jan
7:44 a.m.
On 04/08/2015 08:41 AM, Jan Zelený wrote:
On 7. 4. 2015 at 17:53:42, Ralf Corsepius wrote:
> On 04/07/2015 05:07 PM, Kevin Fenzi wrote:
>> dnf's default behavior is like yum with --skip-broken already.
>
> WHAT?
>
> --skip-broken is a band-aid to work around packaging mistakes and bugs
> and NOT be the default.
>
> IMO, this kind of behavior is not helpful and therefore should be reverted.
This behavior is actually helpful, as it doesn't bother users with a bunch of
broken deps messages they usually don't fully understand (check out how many
of these bugs were filed against yum over the years).
Putting the opinion of myself and the dnf team aside, I'd like to point out
that the information you want is still available - dnf check-update will show
you all the updates, even those that have broken deps. Running this command
right after dnf upgrade will list you those that could not be installed.
Would it please be possible for "dnf update" to print this information
automatically?
E.g. apt-get can say "The following packages have been kept back: ..."
dnf could report it like in this mockup:
...
Dependencies resolved.
========================================================================
Package Arch Version Repository Size
========================================================================
Upgrading:
emacs x86_64 1:24.4-6.fc21 updates-testing 3.0 M
emacs-common x86_64 1:24.4-6.fc21 updates-testing 37 M
emacs-filesystem noarch 1:24.4-6.fc21 updates-testing 64 k
Skipping for dependency reasons:
firefox x86_64 37.0.1-1.fc21 updates-testing 69 M
Transaction Summary
========================================================================
Upgrade 3 Packages
Skip 1 Package
Total download size: ...
Is this ok [y/N]:
Thanks,
Michal
8:30 a.m.
On 8. 4. 2015 at 14:44:25, Michal Schmidt wrote:
On 04/08/2015 08:41 AM, Jan Zelený wrote:
> On 7. 4. 2015 at 17:53:42, Ralf Corsepius wrote:
>> On 04/07/2015 05:07 PM, Kevin Fenzi wrote:
>>> dnf's default behavior is like yum with --skip-broken already.
>>
>> WHAT?
>>
>> --skip-broken is a band-aid to work around packaging mistakes and bugs
>> and NOT be the default.
>>
>> IMO, this kind of behavior is not helpful and therefore should be
>> reverted.
>
> This behavior is actually helpful, as it doesn't bother users with a bunch
> of broken deps messages they usually don't fully understand (check out
> how many of these bugs were filed against yum over the years).
>
> Putting the opinion of myself and the dnf team aside, I'd like to point
> out
> that the information you want is still available - dnf check-update will
> show you all the updates, even those that have broken deps. Running this
> command right after dnf upgrade will list you those that could not be
> installed.
Would it please be possible for "dnf update" to print this information
automatically?
E.g. apt-get can say "The following packages have been kept back: ..."
dnf could report it like in this mockup:
...
Dependencies resolved.
========================================================================
Package Arch Version Repository
Size
========================================================================
Upgrading:
emacs x86_64 1:24.4-6.fc21 updates-testing 3.0 M
emacs-common x86_64 1:24.4-6.fc21 updates-testing 37 M
emacs-filesystem noarch 1:24.4-6.fc21 updates-testing 64 k
Skipping for dependency reasons:
firefox x86_64 37.0.1-1.fc21 updates-testing 69 M
Transaction Summary
========================================================================
Upgrade 3 Packages
Skip 1 Package
Total download size: ...
Is this ok [y/N]:
Thanks,
Michal
Please open an RFE, the dnf devel team is tracking everything in bugzilla,
including priorities. Don't forget to describe the use case ...
Thanks
Jan
8:29 a.m.
On 04/08/2015 08:41 AM, Jan Zelený wrote:
On 7. 4. 2015 at 17:53:42, Ralf Corsepius wrote:
> On 04/07/2015 05:07 PM, Kevin Fenzi wrote:
>> On Tue, 7 Apr 2015 08:38:57 -0500
>>
>> Bruno Wolff III <bruno(a)wolff.to> wrote:
>>> On Tue, Apr 07, 2015 at 10:22:25 -0300,
>>>
>>> Paulo César Pereira de Andrade
>>>
>>> <paulo.cesar.pereira.de.andrade(a)gmail.com> wrote:
>>>> I had also switched back to yum in rawhide due to --skip-broken,
>>>>
>>>> and
>>>> in a few updates not even needing it (I would first see what is
>>>> broken, and if not something "vital", use --skip-broken), while
dnf
>>>> would just fail with cryptic messages. I can keep up if kde or gnome
>>>> is broken, or some other stuff that does not prevent boot and a
>>>> functional system.
>>>
>>> dnf really does need --skip-broken like support if it is to replace
>>> yum. yum can be a lot faster than the needed work around to get dnf
>>> to work equivalently. I am considering going back to yum in rawhide
>>> rather than continuig to test dnf in rawhide because of this issue.
>>
>> dnf's default behavior is like yum with --skip-broken already.
>
> WHAT?
>
> --skip-broken is a band-aid to work around packaging mistakes and bugs
> and NOT be the default.
>
> IMO, this kind of behavior is not helpful and therefore should be reverted.
This behavior is actually helpful, as it doesn't bother users with a bunch of
broken deps messages they usually don't fully understand (check out how many
of these bugs were filed against yum over the years).
I vehemently disagree: Users having been seeing the symptoms of bugs.
Now you are lying and cheating, pretending their systems would be OK in
situations their systems are broken (and potentially vulnerable).
I can not see anything helpful in this behaviour and am not impressed.
Putting the opinion of myself and the dnf team aside, I'd like to
point out
that the information you want is still available - dnf check-update will show
you all the updates, even those that have broken deps. Running this command
right after dnf upgrade will list you those that could not be installed.
This is
similiarly stupid.
With the dnf behavioral change
- dnf needs to inform users about the broken packages by default
- dnf now needs an option which does the opposite to --skip-broken
(--no-skip-broken).
I am very sure you'll see a similiar amount of mails related to broken
packages as before.
Ralf
8:53 a.m.
On 10. 4. 2015 at 15:29:02, Ralf Corsepius wrote:
On 04/08/2015 08:41 AM, Jan Zelený wrote:
> On 7. 4. 2015 at 17:53:42, Ralf Corsepius wrote:
>> On 04/07/2015 05:07 PM, Kevin Fenzi wrote:
>>> On Tue, 7 Apr 2015 08:38:57 -0500
>>>
>>> Bruno Wolff III <bruno(a)wolff.to> wrote:
>>>> On Tue, Apr 07, 2015 at 10:22:25 -0300,
>>>>
>>>> Paulo César Pereira de Andrade
>>>>
>>>> <paulo.cesar.pereira.de.andrade(a)gmail.com> wrote:
>>>>> I had also switched back to yum in rawhide due to --skip-broken,
>>>>>
>>>>> and
>>>>> in a few updates not even needing it (I would first see what is
>>>>> broken, and if not something "vital", use --skip-broken),
while dnf
>>>>> would just fail with cryptic messages. I can keep up if kde or
gnome
>>>>> is broken, or some other stuff that does not prevent boot and a
>>>>> functional system.
>>>>
>>>> dnf really does need --skip-broken like support if it is to replace
>>>> yum. yum can be a lot faster than the needed work around to get dnf
>>>> to work equivalently. I am considering going back to yum in rawhide
>>>> rather than continuig to test dnf in rawhide because of this issue.
>>>
>>> dnf's default behavior is like yum with --skip-broken already.
>>
>> WHAT?
>>
>> --skip-broken is a band-aid to work around packaging mistakes and bugs
>> and NOT be the default.
>>
>> IMO, this kind of behavior is not helpful and therefore should be
>> reverted.
>
> This behavior is actually helpful, as it doesn't bother users with a bunch
> of broken deps messages they usually don't fully understand (check out
> how many of these bugs were filed against yum over the years).
I vehemently disagree: Users having been seeing the symptoms of bugs.
Now you are lying and cheating, pretending their systems would be OK in
situations their systems are broken (and potentially vulnerable).
I can not see anything helpful in this behaviour and am not impressed.
Their systems are not broken (dnf does not install the broken packages), the
repos are broken. I still maintain my opinion that users should not fix
problems of the distribution chain unless they explicitly don't want to, nor
they should see them unless they explicitly don't want to.
Displaying a list of packages that could not be installed because they have
some problems might be ok but that's where I would draw the line.
> Putting the opinion of myself and the dnf team aside, I'd
like to point
> out
> that the information you want is still available - dnf check-update will
> show you all the updates, even those that have broken deps. Running this
> command right after dnf upgrade will list you those that could not be
> installed.
This is similiarly stupid.
With the dnf behavioral change
- dnf needs to inform users about the broken packages by default
- dnf now needs an option which does the opposite to --skip-broken
(--no-skip-broken).
I am very sure you'll see a similiar amount of mails related to broken
packages as before.
To be honest with you, I haven't seen a single one in dnf. If you find it, I
will rest my case.
Thanks
Jan
9:05 a.m.
----- Original Message -----
From: "Jan Zelený" <jzeleny(a)redhat.com>
To: devel(a)lists.fedoraproject.org
Cc: "Ralf Corsepius" <rc040203(a)freenet.de>
Sent: Friday, April 10, 2015 3:53:39 PM
Subject: Re: dnf replacing yum and dnf-yum
On 10. 4. 2015 at 15:29:02, Ralf Corsepius wrote:
> On 04/08/2015 08:41 AM, Jan Zelený wrote:
> > On 7. 4. 2015 at 17:53:42, Ralf Corsepius wrote:
> >> On 04/07/2015 05:07 PM, Kevin Fenzi wrote:
> >>> On Tue, 7 Apr 2015 08:38:57 -0500
> >>>
> >>> Bruno Wolff III <bruno(a)wolff.to> wrote:
> >>>> On Tue, Apr 07, 2015 at 10:22:25 -0300,
> >>>>
> >>>> Paulo César Pereira de Andrade
> >>>>
> >>>> <paulo.cesar.pereira.de.andrade(a)gmail.com> wrote:
> >>>>> I had also switched back to yum in rawhide due to
--skip-broken,
> >>>>>
> >>>>> and
> >>>>> in a few updates not even needing it (I would first see what
is
> >>>>> broken, and if not something "vital", use
--skip-broken), while dnf
> >>>>> would just fail with cryptic messages. I can keep up if kde or
gnome
> >>>>> is broken, or some other stuff that does not prevent boot and
a
> >>>>> functional system.
> >>>>
> >>>> dnf really does need --skip-broken like support if it is to
replace
> >>>> yum. yum can be a lot faster than the needed work around to get
dnf
> >>>> to work equivalently. I am considering going back to yum in
rawhide
> >>>> rather than continuig to test dnf in rawhide because of this
issue.
> >>>
> >>> dnf's default behavior is like yum with --skip-broken already.
> >>
> >> WHAT?
> >>
> >> --skip-broken is a band-aid to work around packaging mistakes and bugs
> >> and NOT be the default.
> >>
> >> IMO, this kind of behavior is not helpful and therefore should be
> >> reverted.
> >
> > This behavior is actually helpful, as it doesn't bother users with a
> > bunch
> > of broken deps messages they usually don't fully understand (check out
> > how many of these bugs were filed against yum over the years).
>
> I vehemently disagree: Users having been seeing the symptoms of bugs.
> Now you are lying and cheating, pretending their systems would be OK in
> situations their systems are broken (and potentially vulnerable).
>
> I can not see anything helpful in this behaviour and am not impressed.
Their systems are not broken (dnf does not install the broken packages), the
repos are broken. I still maintain my opinion that users should not fix
problems of the distribution chain unless they explicitly don't want to, nor
they should see them unless they explicitly don't want to.
I believe Ralf meant that the systems are broken in the sense that they don't have the
latest version (aka the bug-fixed version) of the given package installed.
Displaying a list of packages that could not be installed because
they have
some problems might be ok but that's where I would draw the line.
> > Putting the opinion of myself and the dnf team aside, I'd like to point
> > out
> > that the information you want is still available - dnf check-update will
> > show you all the updates, even those that have broken deps. Running this
> > command right after dnf upgrade will list you those that could not be
> > installed.
> This is similiarly stupid.
>
> With the dnf behavioral change
> - dnf needs to inform users about the broken packages by default
> - dnf now needs an option which does the opposite to --skip-broken
> (--no-skip-broken).
>
> I am very sure you'll see a similiar amount of mails related to broken
> packages as before.
To be honest with you, I haven't seen a single one in dnf. If you find it, I
will rest my case.
Thanks
Jan
--
Radek Holý
Associate Software Engineer
Software Management Team
Red Hat Czech
9:20 a.m.
W dniu 10.04.2015 o 15:29, Ralf Corsepius pisze:
- dnf now needs an option which does the opposite to --skip-broken
(--no-skip-broken).
You mean "dnf update --best"?
Cause (according to my year and half long use of dnf instead of yum) it
is the closest thing to "yum update" you have (without all that
crap^wdebug messages from dependency solver).
9:29 a.m.
Am 10.04.2015 um 16:20 schrieb Marcin Juszkiewicz:
W dniu 10.04.2015 o 15:29, Ralf Corsepius pisze:
> - dnf now needs an option which does the opposite to --skip-broken
> (--no-skip-broken).
You mean "dnf update --best"?
Cause (according to my year and half long use of dnf instead of yum) it
is the closest thing to "yum update" you have (without all that
crap^wdebug messages from dependency solver)
well, that so called "crap" was in the past helpful to find out *which*
package pulls a cross-dep-chain while in the past 2 years yum also more
and more crippeled it's output
it was also helpful in case deps where broken to find out the origin
package responsible for and not only once i decided to remove a specific
package because of that informations
in short: that "crap" was helpful to reach to a minimum stripped down
systems over the years
10:48 a.m.
W dniu 10.04.2015 o 16:29, Reindl Harald pisze:
well, that so called "crap" was in the past helpful to find
out *which*
package pulls a cross-dep-chain while in the past 2 years yum also more
and more crippeled it's output
it was also helpful in case deps where broken to find out the origin
package responsible for and not only once i decided to remove a specific
package because of that informations
in short: that "crap" was helpful to reach to a minimum stripped down
systems over the years
I have no doubt that it was useful in some cases. But probably 90+% of
yum users did not cared about it at all.
10:50 a.m.
Am 10.04.2015 um 17:48 schrieb Marcin Juszkiewicz:
W dniu 10.04.2015 o 16:29, Reindl Harald pisze:
> well, that so called "crap" was in the past helpful to find out *which*
> package pulls a cross-dep-chain while in the past 2 years yum also more
> and more crippeled it's output
>
> it was also helpful in case deps where broken to find out the origin
> package responsible for and not only once i decided to remove a specific
> package because of that informations
>
> in short: that "crap" was helpful to reach to a minimum stripped down
> systems over the years
I have no doubt that it was useful in some cases. But probably 90+% of
yum users did not cared about it at all
but did they got hurted?
unlikely
i really hate that attitude calling remove visible informations
"usability" while systemd on the other hand spits the logs full of
irrelevant informations all day long by burry the relevant ones
3 a.m.
On 10. 4. 2015 at 17:50:08, Reindl Harald wrote:
Am 10.04.2015 um 17:48 schrieb Marcin Juszkiewicz:
> W dniu 10.04.2015 o 16:29, Reindl Harald pisze:
>> well, that so called "crap" was in the past helpful to find out
*which*
>> package pulls a cross-dep-chain while in the past 2 years yum also more
>> and more crippeled it's output
>>
>> it was also helpful in case deps where broken to find out the origin
>> package responsible for and not only once i decided to remove a specific
>> package because of that informations
>>
>> in short: that "crap" was helpful to reach to a minimum stripped down
>> systems over the years
>
> I have no doubt that it was useful in some cases. But probably 90+% of
> yum users did not cared about it at all
but did they got hurted?
unlikely
i really hate that attitude calling remove visible informations
"usability" while systemd on the other hand spits the logs full of
irrelevant informations all day long by burry the relevant ones
We are talking about information that is irrelevant in 90+% of yum runs
(allegedly, I wouldn't dare estimating this number myself). Hiding such
information by default while making it available to people who really care
about it sounds like a nice usability feature to me.
Now, I admit that the second half is limping a bit. The information is
available but it's not as easily accessible as you want it to be. If you want
to help us, I invite you to write a plugin that will show the information you
seek in a way you see fit.
Thanks
Jan
3:22 a.m.
Am 13.04.2015 um 10:00 schrieb Jan Zelený:
We are talking about information that is irrelevant in 90+% of yum
runs
(allegedly, I wouldn't dare estimating this number myself). Hiding such
information by default while making it available to people who really care
about it sounds like a nice usability feature to me.
it is irrelevant in 90% of yum runs?
so what - but it don't hurt
Now, I admit that the second half is limping a bit. The information
is
available but it's not as easily accessible as you want it to be. If you want
to help us, I invite you to write a plugin that will show the information you
seek in a way you see fit
and i invite you to just take the existing code in YUM and re-implement
it because DNF was originally a fork of YUM and somebody has taken
things away to later ask users re-implement them - that's not how the
world works
3:54 a.m.
On Mon, 13 Apr 2015 at 10:22 Reindl Harald <h.reindl(a)thelounge.net>
> Now, I admit that the second half is limping a bit. The information is
> available but it's not as easily accessible as you want it to be. If you
want
> to help us, I invite you to write a plugin that will show the
information you
> seek in a way you see fit
and i invite you to just take the existing code in YUM and re-implement
it because DNF was originally a fork of YUM and somebody has taken
things away to later ask users re-implement them - that's not how the
world works
Yes, this is how the world works in open source development, you can
request all the changes you want, but it up to the upstream project to
select what they want to prioritize and implement.
It is much better if you make some contribution yourself, instead of
complaining, if you want something to change.
DNF is not YUM, it implement mostly the same features, but it is a totally
different codebase, it started as fork og yum many years ago, but they have
moved i differnt directions since then.
You has it owns depsolver written in python, dnf uses a 3 party sat solver.
So it is not possible to take code from the yum delsolver and put it into
dnf, it don't make any sense at all.
I coded the --skip-broken feature in yum and it took many years to get it
right and caused me many gray hairs, the depsolver used in dnf has support
for removing packages from the transaction there is causing problems, but
it is not easy to get information from the solver and present then to the
user in a good way, so I understand that the dnf developers prioritize
there limited time on other things, there matter for more people.
The world is changing al the time, and so does thing in Fedora, mayor parts
is ripped out and replaced all the time, with new stuff there is not
working as the old part. So you have to move on and learn how the new beast
is working for good and bad.
Tim
8:41 a.m.
2015-04-01 16:40 GMT-03:00 Kevin Fenzi <kevin(a)scrye.com>:
There's some confusion around this, so I thought I would post to
try
and clear up things. In the event I am wrong on any of the below, please
do feel free to correct me. ;)
In the past the proposal was to have a yum-dnf package that provided
/usr/bin/yum, called dnf and conflicted with the yum package. I was
against that plan, but I think the one we settled on is worth doing.
It's somewhat of a middle ground between "yum is gone right now,
deal with it" and "you can keep using yum forever".
For f22 (and rawhide):
* dnf is installed by default. By that I mean it is in the 'core' group
in comps.
* dnf-yum is installed by default. By that I mean it is in the 'core'
group in comps next to dnf.
* yum is installed if something that depends on yum pulls it in or say
a user installs it manually.
* yum requires dnf-yum. So, if you install yum manually you will also
pull in dnf-yum (and the dnf plugin that handles history migrate).
* When you run 'yum' you get:
% sudo yum list foobar
Yum command has been deprecated, use dnf instead.
See 'man dnf' and 'man yum2dnf' for more information.
To transfer transaction metadata from yum to DNF, run 'dnf migrate'
Redirecting to '/usr/bin/dnf list foobar'
...then the ouput from dnf list foobar...
* If you wish to still use yum, the yum package provides now
a /usr/bin/yum-deprecated command that is the old yum
command renamed. It also has the notice message as above
on it.
I am using rawhide, and was trying to use dnf sometime ago, and
it was looking promising. But suddenly it stopped being useful,
and yum became again functional, so, I have been using only
yum.
And have been using yum with mock, because it does not work
with dnf, but now, when doing a review, I was surprised with this
in root.log:
DEBUG util.py:452: Executing command: ['/usr/bin/yum',
'--installroot', '/var/lib/mock/fedora-rawhide-x86_64/root/',
'--releasever', '23', 'resolvedep', 'ccache'] with env
{'CCACHE_UMASK': '002', 'LANG': 'en_US.UTF-8',
'HOME': '/builddir',
'CCACHE_DIR': '/tmp/ccache', 'SHELL': '/bin/bash',
'PATH':
'/usr/bin:/bin:/usr/sbin:/sbin', 'LC_MESSAGES': 'C',
'PROMPT_COMMAND':
'printf "\x1b]0;<mock-chroot>\x07<mock-chroot>"',
'TERM': 'vt100',
'HOSTNAME': 'mock'} and shell False
DEBUG util.py:388: Yum command has been deprecated, use dnf instead.
DEBUG util.py:388: See 'man dnf' and 'man yum2dnf' for more information.
DEBUG util.py:388: To transfer transaction metadata from yum to DNF,
run 'dnf migrate'Redirecting to '/usr/bin/dnf --installroot
/var/lib/mock/fedora-rawhide-x86_64/root/ --releasever 23 resolvedep
ccache'
DEBUG util.py:388: No such command: resolvedep. Please use /usr/bin/dnf --help
DEBUG util.py:388: It could be a DNF plugin command.
so, lets run again (without fedora-review -o--yum) to ge back the dnf error
in root.log:
DEBUG util.py:452: Executing command: ['/usr/bin/dnf', 'builddep',
'--installroot', '/var/lib/mock/fedora-rawhide-x86_64/root/',
'--releasever', '23',
'/var/lib/mock/fedora-rawhide-x86_64/root//builddir/build/SRPMS/ebay-cors-filter-1.0.1-1.fc23.src.rpm']
with env {'LANG': 'en_US.UTF-8', 'HOME': '/builddir',
'CCACHE_DIR':
'/tmp/ccache', 'SHELL': '/bin/bash', 'PATH':
'/usr/bin:/bin:/usr/sbin:/sbin', 'PROMPT_COMMAND': 'printf
"\x1b]0;<mock-chroot>\x07<mock-chroot>"', 'HOSTNAME':
'mock',
'LC_MESSAGES': 'C', 'TERM': 'vt100',
'CCACHE_UMASK': '002'} and shell
False
DEBUG util.py:388: No such command: builddep. Please use /usr/bin/dnf --help
DEBUG util.py:388: It could be a DNF plugin command.
I will review using a release other than rawhide.
* If you are using the yum python bindings directly, that will
continue
to work if you have the yum package installed.
Note that this landed before Beta freeze, but there were some issues
with the initial package doing this. There is an update available:
https://admin.fedoraproject.org/updates/yum-3.4.3-505.fc22
I think this helps those users who read any of the docs out there
that say to 'yum install foo' at the cost of those people who need
some specific command line behavior from yum. The second group
is much better positioned to use yum-deprecated or know whats
going on than the first group.
I understand that there is need to update, to use new tools, but
I am afraid, yum only had a small window of time broken for me
some time ago, after that, I could simply not use dnf to update
rawhide, while with yum, sometimes needing --skip-broken (and
doing that when I knew the packages broken would not break
my system), I would be able to update.
kevin
Thanks,
Paulo
9:24 a.m.
On 04/03/2015 03:41 PM, Paulo César Pereira de Andrade wrote:
DEBUG util.py:388: No such command: builddep. Please use
/usr/bin/dnf --help
DEBUG util.py:388: It could be a DNF plugin command.
I will review using a release other than rawhide.
Just install dnf-plugins-core.
But suddenly it stopped being useful,
and yum became again functional, so, I have been using only
yum.
This does not solve anything. Software had bugs, have bugs and will have bugs.
When something is broken, report it. Give developers some time to fix it and return after
some time.
--
Miroslav Suchy, RHCE, RHCDS
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
10:04 a.m.
2015-04-03 11:24 GMT-03:00 Miroslav Suchý <msuchy(a)redhat.com>:
On 04/03/2015 03:41 PM, Paulo César Pereira de Andrade wrote:
> DEBUG util.py:388: No such command: builddep. Please use /usr/bin/dnf --help
> DEBUG util.py:388: It could be a DNF plugin command.
>
> I will review using a release other than rawhide.
Just install dnf-plugins-core.
It should have been installed in an update, e.g. as a dependency
of any packagers tool.
It is also not available in any repo, for rhel7 (I would expect it
in epel). I run mock frequently in rhel7, but usually just as a simple
way to create a rawhide, f22 or f21 chroot.
[[off-topic: Anyway, I made the review on a f21 box in a f21 mock
config, as it required java, and java is currently broken in rawhide.]]
> But suddenly it stopped being useful,
> and yum became again functional, so, I have been using only
> yum.
This does not solve anything. Software had bugs, have bugs and will have bugs.
When something is broken, report it. Give developers some time to fix it and return after
some time.
It is hard to give up on something that looks useful, and I am
afraid, was being better for me than its substitute. Sure I gave
it a try, when yum was broken in rawhide. But when dnf
stopped working, and yum solved the problems, I just switched
back.
--
Miroslav Suchy, RHCE, RHCDS
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
Thanks,
Paulo
10:18 a.m.
2015-04-03 12:04 GMT-03:00 Paulo César Pereira de Andrade
<paulo.cesar.pereira.de.andrade(a)gmail.com>:
2015-04-03 11:24 GMT-03:00 Miroslav Suchý <msuchy(a)redhat.com>:
> On 04/03/2015 03:41 PM, Paulo César Pereira de Andrade wrote:
>> DEBUG util.py:388: No such command: builddep. Please use /usr/bin/dnf --help
>> DEBUG util.py:388: It could be a DNF plugin command.
>>
>> I will review using a release other than rawhide.
>
> Just install dnf-plugins-core.
It should have been installed in an update, e.g. as a dependency
of any packagers tool.
It is also not available in any repo, for rhel7 (I would expect it
in epel). I run mock frequently in rhel7, but usually just as a simple
way to create a rawhide, f22 or f21 chroot.
Nevermind, I thought dnf-plugins-core would be something that would
fix mock chroot generation with fedora-review, it is just documentation,
not related to mock.
Thanks,
Paulo
2:18 p.m.
On Fri, 2015-04-03 at 12:18 -0300, Paulo César Pereira de Andrade wrote:
2015-04-03 12:04 GMT-03:00 Paulo César Pereira de Andrade
<paulo.cesar.pereira.de.andrade(a)gmail.com>:
> 2015-04-03 11:24 GMT-03:00 Miroslav Suchý <msuchy(a)redhat.com>:
> > On 04/03/2015 03:41 PM, Paulo César Pereira de Andrade wrote:
> > > DEBUG util.py:388: No such command: builddep. Please use
> > > /usr/bin/dnf --help
> > > DEBUG util.py:388: It could be a DNF plugin command.
> > >
> > > I will review using a release other than rawhide.
> >
> > Just install dnf-plugins-core.
>
> It should have been installed in an update, e.g. as a dependency
> of any packagers tool.
>
> It is also not available in any repo, for rhel7 (I would expect
> it
> in epel). I run mock frequently in rhel7, but usually just as a
> simple
> way to create a rawhide, f22 or f21 chroot.
Nevermind, I thought dnf-plugins-core would be something that would
fix mock chroot generation with fedora-review, it is just
documentation,
not related to mock.
mock should be adapted to dnf or changed to call yum-deprecated on F22
and F23.
the 'resolvedep' command was already marked as deprecated *in yum*:
* resolvedep dep1 [dep2] [...]
(maintained for legacy reasons only - use repoquery or
yum pro‐
vides)
so mock really should've been ported off it a while back. If there
isn't a bug on mock for this already, we should file one.
As msuchy said, the best thing to do when you encounter something that
has been affected by the transition is to file a bug and get it fixed,
not just use an older release.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
3:42 p.m.
On 2015-04-03 21:18, Adam Williamson wrote:
On Fri, 2015-04-03 at 12:18 -0300, Paulo César Pereira de Andrade
wrote:
> 2015-04-03 12:04 GMT-03:00 Paulo César Pereira de Andrade
> <paulo.cesar.pereira.de.andrade(a)gmail.com>:
>> 2015-04-03 11:24 GMT-03:00 Miroslav Suchý <msuchy(a)redhat.com>:
>>> On 04/03/2015 03:41 PM, Paulo César Pereira de Andrade wrote:
>>>> DEBUG util.py:388: No such command: builddep. Please use
>>>> /usr/bin/dnf --help
>>>> DEBUG util.py:388: It could be a DNF plugin command.
>>>>
>>>> I will review using a release other than rawhide.
>>>
>>> Just install dnf-plugins-core.
>>
>> It should have been installed in an update, e.g. as a dependency
>> of any packagers tool.
>>
>> It is also not available in any repo, for rhel7 (I would expect
>> it
>> in epel). I run mock frequently in rhel7, but usually just as a
>> simple
>> way to create a rawhide, f22 or f21 chroot.
>
> Nevermind, I thought dnf-plugins-core would be something that would
> fix mock chroot generation with fedora-review, it is just
> documentation,
> not related to mock.
mock should be adapted to dnf or changed to call yum-deprecated on F22
and F23.
Mock is adapted to dnf, you just have to tell it to use it in the config
and it is the default on rawhide.
the 'resolvedep' command was already marked as deprecated *in yum*:
* resolvedep dep1 [dep2] [...]
(maintained for legacy reasons only - use repoquery or
yum pro‐
vides)
so mock really should've been ported off it a while back. If there
isn't a bug on mock for this already, we should file
This is only called when mock is using yum and yum still maintains the
command. When mock uses dnf it's not necessary to call it in the first
place, as it was there only to avoid yum skipping missing dependencies,
which dnf builddep doesn't do. If you configure mock to use dnf, it will
work. What doesn't work is when you have it configured to use yum and
yum is a wrapper around dnf, because dnf-yum doesn't provide
yum-builddep (it fails earlier due to resolvedep, but that's not the
real problem, we can get rid of resolvedep, but we need builddep). As
the two package managers don't provide the same command (builddep) under
the same name (yum-builddep vs dnf builddep), mock needs to know which
one it's dealing with, you need to tell it in the config that it's dnf.
The reason why mock exists is to provide reproducible builds. If the
used package manager is dependent on the distro version, it goes agains
the principle. So I think it would be better keep this explicit
configuration instead of using /usr/bin/yum that may point anywhere.
Setting the non-rawhide (target we build for) config default to
yum-deprecated for >f22 (distro mock is running on) looks like a
reasonable solution to me, provided that yum-deprecated works with
yum-builddep.
Michael Simacek
4:07 p.m.
2015-04-03 16:18 GMT-03:00 Adam Williamson <adamwill(a)fedoraproject.org>:
Hmm, let me see if I understand :)
mock should be adapted to dnf or changed to call yum-deprecated on
F22
and F23.
the 'resolvedep' command was already marked as deprecated *in yum*:
* resolvedep dep1 [dep2] [...]
(maintained for legacy reasons only - use repoquery or
yum pro‐
vides)
Apparently yum is no longer an option in rawhide. The first error I had
was because yum is now a wrapper telling yum is deprecated and
exec'ing dnf, with yum arguments, i.e. the resolvedep deprecated
option, it will just fail.
so mock really should've been ported off it a while back. If
there
isn't a bug on mock for this already, we should file one.
It was working, so, this should not really be an issue, as yum is
supposed to be slowly forgotten.
As msuchy said, the best thing to do when you encounter something
that
has been affected by the transition is to file a bug and get it fixed,
not just use an older release.
I just noticed that in f21, dnf-plugins-core actually has a lot of
files, while in rawhide it is only man pages.
There is a kind of related bug report, for f20 at
https://bugzilla.redhat.com/show_bug.cgi?id=1198769
I was wondering why, running manually
/usr/bin/dnf builddep --installroot
/var/lib/mock/fedora-rawhide-x86_64/root/ --releasever 23
/var/lib/mock/fedora-rawhide-x86_64/root/builddir/build/SRPMS/ebay-cors-filter-1.0.1-1.fc23.src.rpm
would work, while mock has this log:
DEBUG util.py:452: Executing command: ['/usr/bin/dnf', 'builddep',
'--installroot', '/var/lib/mock/fedora-rawhide-x86_64/root/',
'--releasever', '23',
'/var/lib/mock/fedora-rawhide-x86_64/root//builddir/build/SRPMS/ebay-cors-filter-1.0.1-1.fc23.src.rpm']
...
DEBUG util.py:388: No such command: builddep. Please use /usr/bin/dnf --help
DEBUG util.py:388: It could be a DNF plugin command.
and this pattern have been happening for quite some time; I think more
than one month, and I just did the simple human thing to do :), that was
to switch to "mock -o--yum", and on rhel7, where I am most time
nowadays, but still trying to do fedora packaging :-), that is the only
option anyway.
Looking at this part of the mock code:
/usr/lib/python3.4/site-packages/mockbuild/package_manager.py:36
if args[0] == 'builddep':
args = args[1:]
invocation += self.builddep_command
common_opts = self.config[self.name + '_builddep_opts']
else:
invocation = [self.command]
common_opts = self.config[self.name + '_common_opts']
invocation += ['--installroot',
self.buildroot.make_chroot_path('')]
it looks like (and in a quick test appears to be it), it would be fixed
with something like:
# echo "config_opts['dnf_builddep_command'] = '/usr/bin/dnf
builddep'"
> /etc/mock/site-defaults.cfg
I will open a bug report about it.
Thanks,
Paulo
2:49 a.m.
On 04/03/2015 11:07 PM, Paulo César Pereira de Andrade wrote:
I just noticed that in f21, dnf-plugins-core actually has a lot of
files, while in rawhide it is only man pages.
That is because dnf-plugins-core requires python3-dnf-plugins-core where the real code of
plugins reside.
--
Miroslav Suchy, RHCE, RHCDS
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
4:49 p.m.
2015-04-03 16:18 GMT-03:00 Adam Williamson <adamwill(a)fedoraproject.org>:
As msuchy said, the best thing to do when you encounter something
that
has been affected by the transition is to file a bug and get it fixed,
not just use an older release.
I opened two bug reports:
[mock with default dnf fails to install dependencies in rawhide]
https://bugzilla.redhat.com/show_bug.cgi?id=1208912
and
[fedora-review gets confused after package build]
https://bugzilla.redhat.com/show_bug.cgi?id=1208914
I did not investigate much the second, just reported what
happened, and that only got there after adding the
dnf_builddep_command option to mocks site-defaults.cfg
Thanks,
Paulo
8:35 p.m.
Kevin Fenzi wrote:
* dnf-yum is installed by default. By that I mean it is in the
'core'
group in comps next to dnf.
[snip]
* If you wish to still use yum, the yum package provides now
a /usr/bin/yum-deprecated command that is the old yum
command renamed. It also has the notice message as above
on it.
IMHO, this is a really bad solution. yum should be yum, dnf should be dnf.
Kevin Kofler
3299
days inactive
3312
days old
117 comments
37 participants
participants (37)
-
Adam Williamson -
Björn Persson -
Bruno Wolff III -
drago01 -
Frank Murphy -
Gerd Hoffmann -
Honza Silhan -
Jan Kratochvil -
Jan Zelený -
Jason L Tibbitts III -
Jiří Konečný -
Josef Stribny -
Kevin Fenzi -
Kevin Kofler -
Marcin Juszkiewicz -
Mathieu Bridon -
Michael Schroeder -
Michael Šimáček -
Michal Luscon -
Michal Schmidt -
Miroslav Suchý -
Nico Kadel-Garcia -
Parag Nemade -
Paulo César Pereira de Andrade -
Pete Travis -
Petr Spacek -
Przemek Klosowski -
Radek Holy -
Rahul Sundaram -
Ralf Corsepius -
Reindl Harald -
Richard Hughes -
Steve Clark -
Till Maas -
Tim Lauridsen -
Tom Hughes -
Vít Ondruch