for localupdate i switched back to yum-deprecated long ago, but for ordinary kernel updates pretend unsolved deps is simply unacceptable
*no* i am not the only one - see karma comments for 4.3.3-300.fc23
https://bugzilla.redhat.com/show_bug.cgi?id=1263888#c14 https://bugzilla.redhat.com/show_bug.cgi?id=1271676
may i suggest to forget that dnf ever existed and switch back to yum?
ongoing problems in the core-task solve dependencies is not production ready AND REMOVE THE DEPRECATED WARNINGS for "package-cleanup" and "yum-deprecated" until DNF is useable and provides the same capabilities as yum/yum-utils
Am Sonntag, den 17.01.2016, 23:27 +0100 schrieb Reindl Harald:
may i suggest to forget that dnf ever existed and switch back to yum?
ongoing problems in the core-task solve dependencies is not production ready AND REMOVE THE DEPRECATED WARNINGS for "package-cleanup" and "yum-deprecated" until DNF is useable and provides the same capabilities as yum/yum-utils
And please don't forget that the autoremove command is unusable at least since somewhere between Fedora 23 beta and final. That's absolutely unacceptable!
So please fix your shit or remove the parts you can't fix! And until then de-deprecate yum until dnf is feature-complete, in a usable stage and you can guarantee dnf will stay in that stage for a long time.
For me a new package manager has to be absolutely reliable and every feature has to work as expected before the new one can replace the current one!
On Sun, Jan 17, 2016 at 11:48:23PM +0100, Heiko Adams wrote:
Am Sonntag, den 17.01.2016, 23:27 +0100 schrieb Reindl Harald:
may i suggest to forget that dnf ever existed and switch back to yum?
ongoing problems in the core-task solve dependencies is not production ready AND REMOVE THE DEPRECATED WARNINGS for "package-cleanup" and "yum-deprecated" until DNF is useable and provides the same capabilities as yum/yum-utils
And please don't forget that the autoremove command is unusable at least since somewhere between Fedora 23 beta and final. That's absolutely unacceptable!
So please fix your shit or remove the parts you can't fix! And until then de-deprecate yum until dnf is feature-complete, in a usable stage and you can guarantee dnf will stay in that stage for a long time.
I would like to point out that this way of communicating is not welcome on this list. If you have something to say, please say it but be respectful in your tone and wording with everyone and everyone's work. We are all on the same boat and shooting each other on the legs isn't going to help. You may want to refresh your memory on our code of conduct: https://getfedora.org/code-of-conduct
Pierre
On Mon, 2016-01-18 at 00:00 +0100, Pierre-Yves Chibon wrote:
On Sun, Jan 17, 2016 at 11:48:23PM +0100, Heiko Adams wrote:
Am Sonntag, den 17.01.2016, 23:27 +0100 schrieb Reindl Harald:
may i suggest to forget that dnf ever existed and switch back to yum?
ongoing problems in the core-task solve dependencies is not production ready AND REMOVE THE DEPRECATED WARNINGS for "package-cleanup" and "yum-deprecated" until DNF is useable and provides the same capabilities as yum/yum-utils
And please don't forget that the autoremove command is unusable at least since somewhere between Fedora 23 beta and final. That's absolutely unacceptable!
So please fix your shit or remove the parts you can't fix! And until then de-deprecate yum until dnf is feature-complete, in a usable stage and you can guarantee dnf will stay in that stage for a long time.
I would like to point out that this way of communicating is not welcome on this list. If you have something to say, please say it but be respectful in your tone and wording with everyone and everyone's work. We are all on the same boat and shooting each other on the legs isn't going to help. You may want to refresh your memory on our code of conduct: https://getfedora.org/code-of-conduct
Pierre
devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject. org
agreed. This is a major reason I choose not to participate on Fedora lists. I can't trust that even the limited code of conduct that exists will even be enforced.
On Sun, 17 Jan 2016 18:23:44 -0500 Johnny Robeson johnny@localmomentum.net wrote:
agreed. This is a major reason I choose not to participate on Fedora lists. I can't trust that even the limited code of conduct that exists will even be enforced.
Yet, you read and are participating here?
In any case feel free to mail the list owners ( devel-owner@lists.fedoraproject.org ) if you feel the code of conduct has been violated.
kevin
Am Montag, den 18.01.2016, 00:00 +0100 schrieb Pierre-Yves Chibon:
On Sun, Jan 17, 2016 at 11:48:23PM +0100, Heiko Adams wrote:
Am Sonntag, den 17.01.2016, 23:27 +0100 schrieb Reindl Harald:
may i suggest to forget that dnf ever existed and switch back to yum?
ongoing problems in the core-task solve dependencies is not production ready AND REMOVE THE DEPRECATED WARNINGS for "package-cleanup" and "yum-deprecated" until DNF is useable and provides the same capabilities as yum/yum-utils
And please don't forget that the autoremove command is unusable at least since somewhere between Fedora 23 beta and final. That's absolutely unacceptable!
So please fix your shit or remove the parts you can't fix! And until then de-deprecate yum until dnf is feature-complete, in a usable stage and you can guarantee dnf will stay in that stage for a long time.
I would like to point out that this way of communicating is not welcome on this list. If you have something to say, please say it but be respectful in your tone and wording with everyone and everyone's work. We are all on the same boat and shooting each other on the legs isn't going to help. You may want to refresh your memory on our code of conduct: https://getfedora.org/code-of-conduct
I apologize for that mail and I'll try to say it more respectful this time:
The first time i noticed the autoerase feature of dnf seems to be broken was somewhere between Fedora 23 beta and final. But it seems to be broken since Feb 2015 [1], which is IMHO unacceptable since a default package manager and all of its features have to work absolutely reliable. And in my case autoerase want's to remove half of my GNOME desktop which seems to be reliable a very bad joke.
But IMHO this reliability seems to be not the case ATM so I'd prefer to rollback the switch from yum to dnf at least until the broken features are fixed and dnf works absolutely reliable (again). And the next time it would be nice if switching the package manager would only affect fresh installations.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1190141
On Mon, Jan 18, 2016 at 12:55:54AM +0100, Heiko Adams wrote:
But it seems to be broken since Feb 2015, which is IMHO unacceptable since a default package manager and all of its features have to work absolutely reliable.
When was the last time you saw a program bigger then /bin/true that was "absolutely reliable"? Your implicit premise that yum was bug free is completely bogus, just look for yum bugs in bugzilla [1].
It seems that with dnf we are currently in the phase of fine-tuning user interaction. The resolver works nicely, there is a growing system of plugins based on a stable API, the codebase was ported to the current version of python, speed is decent most of the time... There *are* things to fix, but calling for the return of yum is a complete waste of the time of everbody on this list.
Zbyszek
[1] https://bugzilla.redhat.com/buglist.cgi?classification=Fedora&component=...
On 18 January 2016 at 01:32, Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Mon, Jan 18, 2016 at 12:55:54AM +0100, Heiko Adams wrote:
But it seems to be broken since Feb 2015, which is IMHO unacceptable since a default package manager and all of its features have to work absolutely reliable.
When was the last time you saw a program bigger then /bin/true that was "absolutely reliable"? Your implicit premise that yum was bug free is completely bogus, just look for yum bugs in bugzilla [1].
xz tar cp ...
Being reliable might be difficult, but it is achievable, and the more core a tool is the more important it is that it approaches reliability.
It seems that with dnf we are currently in the phase of fine-tuning user interaction. The resolver works nicely, there is a growing system of plugins based on a stable API, the codebase was ported to the current version of python, speed is decent most of the time... There *are* things to fix, but calling for the return of yum is a complete waste of the time of everbody on this list.
So there's no need to fight hyperbole with hyperbole.
On Mon, Jan 18, 2016 at 08:46:06AM +0000, Ian Malone wrote:
On 18 January 2016 at 01:32, Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Mon, Jan 18, 2016 at 12:55:54AM +0100, Heiko Adams wrote:
But it seems to be broken since Feb 2015, which is IMHO unacceptable since a default package manager and all of its features have to work absolutely reliable.
When was the last time you saw a program bigger then /bin/true that was "absolutely reliable"? Your implicit premise that yum was bug free is completely bogus, just look for yum bugs in bugzilla [1].
xz tar cp ...
I'd argue that those three programs aren't that far from /bin/true in terms of complexity. And if you look in the bugzilla, all three of those *do* have occasional bugs. And they are missing features: xz still does not support parallel compression, and people have been asking for it for years. tar does not support ACLS, etc.
https://bugzilla.redhat.com/buglist.cgi?classification=Fedora&component=... https://bugzilla.redhat.com/buglist.cgi?classification=Fedora&component=... https://bugzilla.redhat.com/buglist.cgi?classification=Fedora&component=...
Being reliable might be difficult, but it is achievable, and the more core a tool is the more important it is that it approaches reliability.
You can't really compare programs which have a single purpose and a simple user interface and for which there is one obvious way to do things with a sprawling beast of a program that has plugins, hundreds of options, deals with the network, needs various heuristics for speed, depends on other libraries, ... and is just complex.
It seems that with dnf we are currently in the phase of fine-tuning user interaction. The resolver works nicely, there is a growing system of plugins based on a stable API, the codebase was ported to the current version of python, speed is decent most of the time... There *are* things to fix, but calling for the return of yum is a complete waste of the time of everbody on this list.
So there's no need to fight hyperbole with hyperbole.
Do you really think that there's any chance of us returning to yum? Or a reason to advocate that? There doesn't seem to be, so it *is* a complete waste of time and this is not hyperbole.
Zbyszek
Am 18.01.2016 um 02:32 schrieb Zbigniew Jędrzejewski-Szmek:
On Mon, Jan 18, 2016 at 12:55:54AM +0100, Heiko Adams wrote:
But it seems to be broken since Feb 2015, which is IMHO unacceptable since a default package manager and all of its features have to work absolutely reliable.
When was the last time you saw a program bigger then /bin/true that was "absolutely reliable"? Your implicit premise that yum was bug free is completely bogus, just look for yum bugs in bugzilla [1].
It seems that with dnf we are currently in the phase of fine-tuning user interaction. The resolver works nicely
the resolver works NOT nicely - hence that whole thread and bugreport
I hope Heiko Adams and Reindl Harald should co-operate and write usable and bug free package manager.
Related to topic: Please prepare full list of bugs which you think critical for you and write to each how to reproduce it.
P.S. autoremove works here fine (fresh 23).
On Sun, Jan 17, 2016, 11:48 PM Heiko Adams ml@fedora-blog.de wrote:
Am Sonntag, den 17.01.2016, 23:27 +0100 schrieb Reindl Harald:
may i suggest to forget that dnf ever existed and switch back to yum?
ongoing problems in the core-task solve dependencies is not production ready AND REMOVE THE DEPRECATED WARNINGS for "package-cleanup" and "yum-deprecated" until DNF is useable and provides the same capabilities as yum/yum-utils
And please don't forget that the autoremove command is unusable at least since somewhere between Fedora 23 beta and final. That's absolutely unacceptable!
So please fix your shit or remove the parts you can't fix! And until then de-deprecate yum until dnf is feature-complete, in a usable stage and you can guarantee dnf will stay in that stage for a long time.
For me a new package manager has to be absolutely reliable and every feature has to work as expected before the new one can replace the current one! -- Regards,
Heiko Adams
-- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
On 18 Jan 2016 06:33, "Igor Gnatenko" i.gnatenko.brain@gmail.com wrote:
I hope Heiko Adams and Reindl Harald should co-operate and write usable
and bug free package manager.
Related to topic: Please prepare full list of bugs which you think
critical for you and write to each how to reproduce it.
P.S. autoremove works here fine (fresh 23).
The autoremove reference might be the well known issue with packagekit, not dnf, that is not marking packages as installed rather than dependencies.
The default dnf configuration is autoremove so that doesn't then know that have been specifically installed rather than just unneeded dependencies of something else and then helpfully tries to remove them...
Note this is a result of a packagekit bug not dnf.
On a side note it'd be nice if pk just called out to dnf so that they have a common backend which would prevent behaviour like this and would result in sharing a history database as well.
On Mon, Jan 18, 2016 at 2:52 AM, James Hogarth james.hogarth@gmail.com wrote:
On 18 Jan 2016 06:33, "Igor Gnatenko" i.gnatenko.brain@gmail.com wrote:
I hope Heiko Adams and Reindl Harald should co-operate and write usable and bug free package manager.
Related to topic: Please prepare full list of bugs which you think critical for you and write to each how to reproduce it.
P.S. autoremove works here fine (fresh 23).
The autoremove reference might be the well known issue with packagekit, not dnf, that is not marking packages as installed rather than dependencies.
The default dnf configuration is autoremove so that doesn't then know that have been specifically installed rather than just unneeded dependencies of something else and then helpfully tries to remove them...
Note this is a result of a packagekit bug not dnf.
On a side note it'd be nice if pk just called out to dnf so that they have a common backend which would prevent behaviour like this and would result in sharing a history database as well.
Or at least wrote information to a common database so that all the information is synchronized[0].
Note that with hawkey now merged into libhif, DNF will be using libhif, which makes it even more silly that PackageKit-Hif and DNF still don't keep each other in sync.
[0]: https://bugzilla.redhat.com/show_bug.cgi?id=1167239
On 18/01/16 03:28 -0500, Neal Gompa wrote:
On Mon, Jan 18, 2016 at 2:52 AM, James Hogarth james.hogarth@gmail.com wrote:
On a side note it'd be nice if pk just called out to dnf so that they have a common backend which would prevent behaviour like this and would result in sharing a history database as well.
Or at least wrote information to a common database so that all the information is synchronized[0].
Note that with hawkey now merged into libhif, DNF will be using libhif, which makes it even more silly that PackageKit-Hif and DNF still don't keep each other in sync.
Yes, the lack of PK and DNF integration is a bigger problem than some of DNF's peculiarities, and leads to very poor user experiences. For example when PK tells you there are updates and you apply them via DNF on the command-line, then tell PK to "Install Updates" it tells you there is an internal system error and to contact your system administrator. "Already updated" should not be an "internal system error"!
And the fact that /var/log/dnf.rpm.log doesn't show updates done by PK is just annoying. Isn't there a single log file I can look at to see what was updated, and when?
Am 18.01.2016 um 13:16 schrieb Jonathan Wakely:
And the fact that /var/log/dnf.rpm.log doesn't show updates done by PK is just annoying. Isn't there a single log file I can look at to see what was updated, and when?
currently no because dnf, PK and yum-deprecated using different logging instead just point to a generic "/var/log/packages.log" or how ever called
that's also annoying when you need to use yum-deprecated to get your tasks done, at least that and https://bugzilla.redhat.com/show_bug.cgi?id=1273925 could have been avoided (logwatch would have then contained the informations scratched with the premature logrotate)
Am 18.01.2016 um 13:16 schrieb Jonathan Wakely:
And the fact that /var/log/dnf.rpm.log doesn't show updates done by PK is just annoying. Isn't there a single log file I can look at to see what was updated, and when?
currently no because dnf, PK and yum-deprecated using different logging instead just point to a generic "/var/log/packages.log" or how ever called
that's also annoying when you need to use yum-deprecated to get your tasks done, at least that and https://bugzilla.redhat.com/show_bug.cgi?id=1273925 could have been avoided (logwatch would have then contained the informations scratched with the premature logrotate)
-- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
From: "James Hogarth" james.hogarth@gmail.com On 18 Jan 2016 06:33, "Igor Gnatenko" < i.gnatenko.brain@gmail.com > wrote:
I hope Heiko Adams and Reindl Harald should co-operate and write usable and bug free package manager.
Related to topic: Please prepare full list of bugs which you think critical for you and write to each how to reproduce it.
P.S. autoremove works here fine (fresh 23).
The autoremove reference might be the well known issue with packagekit, not dnf, that is not marking packages as installed rather than dependencies.
The default dnf configuration is autoremove so that doesn't then know that have been specifically installed rather than just unneeded dependencies of something else and then helpfully tries to remove them...
Note this is a result of a packagekit bug not dnf.
On a side note it'd be nice if pk just called out to dnf so that they have a common backend which would prevent behaviour like this and would result in sharing a history database as well.
yes, autoremoval issue could be either caused by bad packaging [1] or when you are installing packages via yum or packagekit [2]. We are working on better integration between DNF and PK so this could be fixed soon. At the meantime use this workaround [3].
From: "Reindl Harald" h.reindl@thelounge.net Am 18.01.2016 um 00:48 schrieb Kevin Fenzi:
Reindl Harald h.reindl@thelounge.net wrote:
...snip...
"dnf update *.rpm" is the way which has to work
Why? It works fine as a install. It's installing a new kernel, since kernels can have many versions installed at a time it makes more sense for it to be a install than an upgrade (which would imply that the old version would be removed).
why?
because you don't type "dnf install kernel" instead "dnf upgrade" and "kernel-headers" *is never installed* in multiple versions
This seems like a matter of taste. If you want to keep yearly logs, set your logrotate that way.
AFAIR the config files are not config noreplace"
The spec seems to have: %config(noreplace) %{_sysconfdir}/logrotate.d/%{name}
well, give it a try, but for many years you had yum-logs for the complete year rotated once on the begin of a new year - package updates are not that often and don#t flood logs like some systemd things
Then I am closing this bug, thanks for cooperation.
Honza
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1222812#c23 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1259865 [3] http://dnf.baseurl.org/2015/10/26/mark-command-usecase/
Am Montag, den 18.01.2016, 07:05 -0500 schrieb Honza Šilhan:
From: "James Hogarth" james.hogarth@gmail.com The autoremove reference might be the well known issue with packagekit, not dnf, that is not marking packages as installed rather than dependencies.
The default dnf configuration is autoremove so that doesn't then know that have been specifically installed rather than just unneeded dependencies of something else and then helpfully tries to remove them...
Note this is a result of a packagekit bug not dnf.
On a side note it'd be nice if pk just called out to dnf so that they have a common backend which would prevent behaviour like this and would result in sharing a history database as well.
yes, autoremoval issue could be either caused by bad packaging [1] or when you are installing packages via yum or packagekit [2]. We are working on better integration between DNF and PK so this could be fixed soon. At the meantime use this workaround [3]. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1222812#c23 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1259865 [3] http://dnf.baseurl.org/2015/10/26/mark-command-usecase/
That workaround is only useable if you know what packages you've installed via PK but because this issue exists nearly since a year that could be hard to remember what pacakges were installed via PK.
On 18/01/16 07:05 -0500, Honza Šilhan wrote:
yes, autoremoval issue could be either caused by bad packaging [1] or when you are installing packages via yum or packagekit [2]. We are working on better integration between DNF and PK so this could be fixed soon. At the meantime use this workaround [3].
It's a *terrible* workaround though. "Make a note of everything that gets installed using PK and then as root run dnf to mark them as userinstalled". A better workaround is "Don't use PK to install things, use DNF". Why bother using PK at all if you then have to go and run DNF commands for the same packages? You might as well just use DNF.
On Mon, Jan 18, 2016 at 7:27 AM, Jonathan Wakely jwakely@fedoraproject.org wrote:
On 18/01/16 07:05 -0500, Honza Šilhan wrote:
yes, autoremoval issue could be either caused by bad packaging [1] or when you are installing packages via yum or packagekit [2]. We are working on better integration between DNF and PK so this could be fixed soon. At the meantime use this workaround [3].
It's a *terrible* workaround though. "Make a note of everything that gets installed using PK and then as root run dnf to mark them as userinstalled". A better workaround is "Don't use PK to install things, use DNF". Why bother using PK at all if you then have to go and run DNF commands for the same packages? You might as well just use DNF.
Honestly, I wonder why we didn't just have PackageKit have a DNF backend directly, instead. It seems like we created some very weird problems by having two independent package managers that can't even talk to each other. Maybe we should just tell people to use yumex-dnf, since it just calls DNF APIs through dnfdaemon, and I believe those transactions remain in sync.
Doing things like having PK shell out to call dnf mark just makes things really odd.
Am Montag, den 18.01.2016, 12:27 +0000 schrieb Jonathan Wakely:
On 18/01/16 07:05 -0500, Honza Šilhan wrote:
yes, autoremoval issue could be either caused by bad packaging [1] or when you are installing packages via yum or packagekit [2]. We are working on better integration between DNF and PK so this could be fixed soon. At the meantime use this workaround [3].
It's a *terrible* workaround though. "Make a note of everything that gets installed using PK and then as root run dnf to mark them as userinstalled". A better workaround is "Don't use PK to install things, use DNF". Why bother using PK at all if you then have to go and run DNF commands for the same packages? You might as well just use DNF.
Because sometimes PK says there are updates available while "dnf update --refresh" says no updates are available? Happend to me several times in the past.
Am 18.01.2016 um 13:39 schrieb Heiko Adams:
Am Montag, den 18.01.2016, 12:27 +0000 schrieb Jonathan Wakely:
On 18/01/16 07:05 -0500, Honza Šilhan wrote:
yes, autoremoval issue could be either caused by bad packaging [1] or when you are installing packages via yum or packagekit [2]. We are working on better integration between DNF and PK so this could be fixed soon. At the meantime use this workaround [3].
It's a *terrible* workaround though. "Make a note of everything that gets installed using PK and then as root run dnf to mark them as userinstalled". A better workaround is "Don't use PK to install things, use DNF". Why bother using PK at all if you then have to go and run DNF commands for the same packages? You might as well just use DNF.
Because sometimes PK says there are updates available while "dnf update --refresh" says no updates are available? Happend to me several times in the past.
that's the drawback of dnf-makecache.timer because it may cache something shortly before updates are pushed and without that caching it would be refresehd when it's attempted to be used and so contain recent data
mask that timer and you are done that never should have been introduced as default
the logflood "Cannot add dependency job for unit dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked" should go away soon (referenced in a different thread and a systemd bugreport of some otehr person)
Am 18.01.2016 um 13:39 schrieb Heiko Adams:
Am Montag, den 18.01.2016, 12:27 +0000 schrieb Jonathan Wakely:
On 18/01/16 07:05 -0500, Honza Šilhan wrote:
yes, autoremoval issue could be either caused by bad packaging [1] or when you are installing packages via yum or packagekit [2]. We are working on better integration between DNF and PK so this could be fixed soon. At the meantime use this workaround [3].
It's a *terrible* workaround though. "Make a note of everything that gets installed using PK and then as root run dnf to mark them as userinstalled". A better workaround is "Don't use PK to install things, use DNF". Why bother using PK at all if you then have to go and run DNF commands for the same packages? You might as well just use DNF.
Because sometimes PK says there are updates available while "dnf update --refresh" says no updates are available? Happend to me several times in the past.
that's the drawback of dnf-makecache.timer because it may cache something shortly before updates are pushed and without that caching it would be refresehd when it's attempted to be used and so contain recent data
mask that timer and you are done that never should have been introduced as default
the logflood "Cannot add dependency job for unit dnf-makecache.timer, ignoring: Unit dnf-makecache.timer is masked" should go away soon (referenced in a different thread and a systemd bugreport of some otehr person)
-- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
On Mon, Jan 18, 2016 at 7:27 AM, Jonathan Wakely jwakely@fedoraproject.org wrote:
On 18/01/16 07:05 -0500, Honza Šilhan wrote:
yes, autoremoval issue could be either caused by bad packaging [1] or when you are installing packages via yum or packagekit [2]. We are working on better integration between DNF and PK so this could be fixed soon. At the meantime use this workaround [3].
It's a *terrible* workaround though. "Make a note of everything that gets installed using PK and then as root run dnf to mark them as userinstalled". A better workaround is "Don't use PK to install things, use DNF". Why bother using PK at all if you then have to go and run DNF commands for the same packages? You might as well just use DNF.
Honestly, I wonder why we didn't just have PackageKit have a DNF backend directly, instead. It seems like we created some very weird problems by having two independent package managers that can't even talk to each other. Maybe we should just tell people to use yumex-dnf, since it just calls DNF APIs through dnfdaemon, and I believe those transactions remain in sync.
Doing things like having PK shell out to call dnf mark just makes things really odd.
On Seg, 2016-01-18 at 07:37 -0500, Neal Gompa wrote:
On Mon, Jan 18, 2016 at 7:27 AM, Jonathan Wakely jwakely@fedoraproject.org wrote:
On 18/01/16 07:05 -0500, Honza Šilhan wrote:
yes, autoremoval issue could be either caused by bad packaging [1] or when you are installing packages via yum or packagekit [2]. We are working on better integration between DNF and PK so this could be fixed soon. At the meantime use this workaround [3].
It's a *terrible* workaround though. "Make a note of everything that gets installed using PK and then as root run dnf to mark them as userinstalled". A better workaround is "Don't use PK to install things, use DNF". Why bother using PK at all if you then have to go and run DNF commands for the same packages? You might as well just use DNF.
Honestly, I wonder why we didn't just have PackageKit have a DNF backend directly, instead.
https://bugzilla.redhat.com/show_bug.cgi?id=1256108
except that don't found any bug .
It seems like we created some very weird problems by having two independent package managers that can't even talk to each other. Maybe we should just tell people to use yumex- dnf, since it just calls DNF APIs through dnfdaemon, and I believe those transactions remain in sync.
Doing things like having PK shell out to call dnf mark just makes things really odd.
Am Montag, den 18.01.2016, 07:05 -0500 schrieb Honza Šilhan:
From: "James Hogarth" james.hogarth@gmail.com The autoremove reference might be the well known issue with packagekit, not dnf, that is not marking packages as installed rather than dependencies.
The default dnf configuration is autoremove so that doesn't then know that have been specifically installed rather than just unneeded dependencies of something else and then helpfully tries to remove them...
Note this is a result of a packagekit bug not dnf.
On a side note it'd be nice if pk just called out to dnf so that they have a common backend which would prevent behaviour like this and would result in sharing a history database as well.
yes, autoremoval issue could be either caused by bad packaging [1] or when you are installing packages via yum or packagekit [2]. We are working on better integration between DNF and PK so this could be fixed soon. At the meantime use this workaround [3]. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1222812#c23 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1259865 [3] http://dnf.baseurl.org/2015/10/26/mark-command-usecase/
That workaround is only useable if you know what packages you've installed via PK but because this issue exists nearly since a year that could be hard to remember what pacakges were installed via PK.
On Sun, 17 Jan 2016 23:27:02 +0100 Reindl Harald h.reindl@thelounge.net wrote:
for localupdate i switched back to yum-deprecated long ago, but for ordinary kernel updates pretend unsolved deps is simply unacceptable
*no* i am not the only one - see karma comments for 4.3.3-300.fc23
But your comment doesn't explain what you are even doing. What was the command and all output?
For localling installing new kernel versions, I use 'dnf install' and it works just fine here.
https://bugzilla.redhat.com/show_bug.cgi?id=1263888#c14 https://bugzilla.redhat.com/show_bug.cgi?id=1271676
This seems like a matter of taste. If you want to keep yearly logs, set your logrotate that way.
may i suggest to forget that dnf ever existed and switch back to yum?
You can suggest it, but it's not going to happen, so I'd advise relaxing some and working with dnf developers.
I'd encourage you to re-read our code of conduct ( https://getfedora.org/code-of-conduct ) and try and be more respectful in bugs and here. We are all trying to improve things, lets work together.
kevin
Am 17.01.2016 um 23:54 schrieb Kevin Fenzi:
On Sun, 17 Jan 2016 23:27:02 +0100 Reindl Harald h.reindl@thelounge.net wrote:
for localupdate i switched back to yum-deprecated long ago, but for ordinary kernel updates pretend unsolved deps is simply unacceptable
*no* i am not the only one - see karma comments for 4.3.3-300.fc23
But your comment doesn't explain what you are even doing. What was the command and all output?
just "dnf upgrade" and DNF don't give any useful output, even not with "dnf -v upgrade" in the last case with *no local* packages
For localling installing new kernel versions, I use 'dnf install' and it works just fine here.
"dnf update *.rpm" is the way which has to work
https://bugzilla.redhat.com/show_bug.cgi?id=1263888#c14 https://bugzilla.redhat.com/show_bug.cgi?id=1271676
This seems like a matter of taste. If you want to keep yearly logs, set your logrotate that way.
AFAIR the config files are not config noreplace"
may i suggest to forget that dnf ever existed and switch back to yum?
You can suggest it, but it's not going to happen, so I'd advise relaxing some and working with dnf developers.
what more than report bugs months ago which can be reprodcued with nearly every "dnf update *.rpm" when there are sub-packages with inter-dependencies
better adivse the dnf evelopers to work together with reporters and just try "dnf update *.rpm" which worked in case of "yum update *.rpm" forever
I'd encourage you to re-read our code of conduct ( https://getfedora.org/code-of-conduct ) and try and be more respectful in bugs and here. We are all trying to improve things, lets work together
in case of such obvious bugs this *is* resepectful
On Sun, Jan 17, 2016 at 6:01 PM, Reindl Harald h.reindl@thelounge.net wrote:
Am 17.01.2016 um 23:54 schrieb Kevin Fenzi:
I'd encourage you to re-read our code of conduct ( https://getfedora.org/code-of-conduct ) and try and be more respectful in bugs and here. We are all trying to improve things, lets work together
in case of such obvious bugs this *is* resepectful
No, it is not. Your tone and method of communication is highly antagonistic in nature on both mailing lists and in bugs you've filed in the Red Hat Bugzilla, and it's very hard to be willing to even consider issues you experience when you continue to maintain such a tone while trying to seek assistance or trying to get something fixed.
Fedora is a large community and all of us love using and developing the distribution. Passions may get a bit hot, but we should always be respectful and constructive. We also don't live in isolation, and work with other communities to develop excellent solutions that everyone can use, including the many projects and products that are downstream from Fedora.
And if you really want something fixed that badly, talk to the DNF development team about contributing to fix particular issues, or even work with them one-on-one to help them fix it properly. Suggesting to throw out DNF and re-instate Yum is not helpful and makes it really easy to ignore you.
Am 18.01.2016 um 00:08 schrieb Neal Gompa:
On Sun, Jan 17, 2016 at 6:01 PM, Reindl Harald h.reindl@thelounge.net wrote:
Am 17.01.2016 um 23:54 schrieb Kevin Fenzi:
I'd encourage you to re-read our code of conduct ( https://getfedora.org/code-of-conduct ) and try and be more respectful in bugs and here. We are all trying to improve things, lets work together
in case of such obvious bugs this *is* resepectful
No, it is not. Your tone and method of communication is highly antagonistic in nature on both mailing lists and in bugs you've filed in the Red Hat Bugzilla, and it's very hard to be willing to even consider issues you experience when you continue to maintain such a tone while trying to seek assistance or trying to get something fixed.
and replace a perfect working package manager is respectful to users?
Fedora is a large community and all of us love using and developing the distribution. Passions may get a bit hot, but we should always be respectful and constructive. We also don't live in isolation, and work with other communities to develop excellent solutions that everyone can use, including the many projects and products that are downstream from Fedora.
dnf is far away from "excellent solutions"
just the fact that there are no useful outputs about the nature of a (mostly pretended) dependency problem disqualifies it while "yum-deprecated" shows you even soname-conflicts in a clear way
the case where i had enough again and wrote the mail above was a "dnf -v upgrade" with no useful output and "yum-deprecated upgrade" just worked fine as all the years ago - so *there is no* dependency problem
And if you really want something fixed that badly, talk to the DNF development team about contributing to fix particular issues, or even work with them one-on-one to help them fix it properly. Suggesting to throw out DNF and re-instate Yum is not helpful and makes it really easy to ignore you.
it would be enough to *remove* all that deprecation warnings for "yum-deprecated" and "package-cleanup" so that i could set an alias back to yum-deprecated
On Mon, 18 Jan 2016 00:01:13 +0100 Reindl Harald h.reindl@thelounge.net wrote:
...snip...
"dnf update *.rpm" is the way which has to work
Why? It works fine as a install. It's installing a new kernel, since kernels can have many versions installed at a time it makes more sense for it to be a install than an upgrade (which would imply that the old version would be removed).
https://bugzilla.redhat.com/show_bug.cgi?id=1263888#c14 https://bugzilla.redhat.com/show_bug.cgi?id=1271676
This seems like a matter of taste. If you want to keep yearly logs, set your logrotate that way.
AFAIR the config files are not config noreplace"
The spec seems to have: %config(noreplace) %{_sysconfdir}/logrotate.d/%{name}
kevin
Am 18.01.2016 um 00:48 schrieb Kevin Fenzi:
On Mon, 18 Jan 2016 00:01:13 +0100 Reindl Harald h.reindl@thelounge.net wrote:
...snip...
"dnf update *.rpm" is the way which has to work
Why? It works fine as a install. It's installing a new kernel, since kernels can have many versions installed at a time it makes more sense for it to be a install than an upgrade (which would imply that the old version would be removed).
why?
because you don't type "dnf install kernel" instead "dnf upgrade" and "kernel-headers" *is never installed* in multiple versions
https://bugzilla.redhat.com/show_bug.cgi?id=1263888#c14 https://bugzilla.redhat.com/show_bug.cgi?id=1271676
This seems like a matter of taste. If you want to keep yearly logs, set your logrotate that way.
AFAIR the config files are not config noreplace"
The spec seems to have: %config(noreplace) %{_sysconfdir}/logrotate.d/%{name}
well, give it a try, but for many years you had yum-logs for the complete year rotated once on the begin of a new year - package updates are not that often and don#t flood logs like some systemd things
On Mon, 18 Jan 2016 00:53:00 +0100 Reindl Harald h.reindl@thelounge.net wrote:
...snip...
why?
because you don't type "dnf install kernel" instead "dnf upgrade" and "kernel-headers" *is never installed* in multiple versions
Sure, you want upgrade/update to update installonly pkgs too.
In any case 'dnf install' will work for locally downloaded kernel rpms, which was your case right? so it should work as a workaround at least for now, no?
kevin
Am 18.01.2016 um 04:16 schrieb Kevin Fenzi:
On Mon, 18 Jan 2016 00:53:00 +0100 Reindl Harald h.reindl@thelounge.net wrote:
...snip...
why?
because you don't type "dnf install kernel" instead "dnf upgrade" and "kernel-headers" *is never installed* in multiple versions
Sure, you want upgrade/update to update installonly pkgs too.
In any case 'dnf install' will work for locally downloaded kernel rpms, which was your case right? so it should work as a workaround at least for now, no?
the case of *that thread* was a ordinary "dnf upgrade" with no local packages involved
i think "for localupdate i switched back to yum-deprecated long ago, but for ordinary kernel updates pretend unsolved deps is simply unacceptable" was pretty clear - see the "but" - i gave up with dnf long ago
On Mon, 18 Jan 2016 10:22:11 +0100 Reindl Harald h.reindl@thelounge.net wrote:
the case of *that thread* was a ordinary "dnf upgrade" with no local packages involved
ok. I think we are talking about different things then. I was addressing the issue where you download kernel rpms and dnf won't let you 'update' them, you have to 'install'.
i think "for localupdate i switched back to yum-deprecated long ago, but for ordinary kernel updates pretend unsolved deps is simply unacceptable" was pretty clear - see the "but" - i gave up with dnf long ago
Well, thats your choice, but note that yum will go away at some point.
kevin