Re: F18 DNF and history
On Mon, Jun 25, 2012 at 05:09:17PM -0400, James Antill wrote: On Fri, 2012-06-22 at 09:56 +0200, Matej Cepl wrote: Then the curious minds ask ... why clean_requirements_on_remove = 1 isn't a default? The main two main reasons we didn't just turn it on when written are: 1. New code in a pretty critical operation, needs to be tested a bunch first. 2. Lots of people would have installed packages without a reason set. ...both of which should be gone now, so we could turn it on by default in F18. I turned this on in my yum.conf and this is the first upgrade where yum offered to remove packages. You'll want to be careful how packages are specified during the install: the latest upgrade of dracut no longer requires plymouth. Since nothing else does, yum was offering to uninstall it for me--until I changed its reason. -- Scott Schmit smime.p7s Description: S/MIME cryptographic signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yum pragma: no-cache (was Re: F18 DNF and history)
Le Ven 22 juin 2012 15:22, Reindl Harald a écrit : Am 22.06.2012 15:17, schrieb Zdenek Pavlas: From: Nicolas Mailhot nicolas.mail...@laposte.net can we get a package downloader that sends the correct cache-control http headers to refresh data automatically instead of complaining metadata is wrong and aborting (for people behind a caching proxy)? Have you tried changing http_caching option in yum.conf from (default) 'all' to 'packages'? this is nothing which can be controlled properly by the client - the server is responsible for caching-headers Cache-Control: private Pragma: private and no longer will any proxy cache the file while the client itself is allowed to do so this is the only technical clean solution for people behind a caching proxy and the problem a proxy may have cached wrong metadata Thank you very much I know how a proxy works. My beef with yum is that after years of reports it does not seem to know how how proxy work yet, and offers only an all-or-nothing manual http_caching hammer when things should work transparently with proxies by default. But, anyway: 1. The only item that should require retrieving with caching off is the master index file since all the other index files can be made trivialy proxy-safe by using unique (timestamped) names and can be referenced from this file. 2. to force no caching of this file it should include the correct cache control metadata (probably forces it to be an xhtml or html file since most equipments won't read this metadata elsewhere). That is, absent a way to control the headers send by mirrors which seems challenging organisationnaly (though an adding an .htaccess file with the correct instructions could help) 3. yum should always send Pragma: No-cache or Cache-Control: no-cache when retrieving this file Regards -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yum pragma: no-cache (was Re: F18 DNF and history)
Am 22.06.2012 15:17, schrieb Zdenek Pavlas: From: Nicolas Mailhot nicolas.mail...@laposte.net can we get a package downloader that sends the correct cache-control http headers to refresh data automatically instead of complaining metadata is wrong and aborting (for people behind a caching proxy)? Have you tried changing http_caching option in yum.conf from (default) 'all' to 'packages'? this is nothing which can be controlled properly by the client - the server is responsible for caching-headers Cache-Control: private Pragma: private and no longer will any proxy cache the file while the client itself is allowed to do so this is the only technical clean solution for people behind a caching proxy and the problem a proxy may have cached wrong metadata you do this typically in any webapplication if you deliver content only available after login signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F18 DNF and history
On Fri, 2012-06-22 at 10:02 +0200, Matej Cepl wrote: On 21/06/12 16:54, Michal Schmidt wrote: http://skvidal.wordpress.com/2010/11/09/orphaned-dep-cleanup-in-yum/ Is there some post-processing tool which would should me all packages for which there is no reason? Brief look at the source of packages-cleanup shows that --orphans isn't the one. You want the yumdb command in yum-utils. Eg. yumdb unset reason '*' signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F18 DNF and history
On Fri, 2012-06-22 at 09:56 +0200, Matej Cepl wrote: On 21/06/12 16:54, Michal Schmidt wrote: On 06/21/2012 04:27 PM, Nikola Pajkovsky wrote: Michal Schmidt mschm...@redhat.com writes: We do now. You can set clean_requirements_on_remove=1 in yum.conf in which version that is supported? Since 3.2.28-13 http://skvidal.wordpress.com/2010/11/09/orphaned-dep-cleanup-in-yum/ Mea culpa! I have missed we weren’t using the ‘reason’ info we’re now storing in the yumdb to know what is a dep and what is not which is a crucial piece of information. Then the curious minds ask ... why clean_requirements_on_remove = 1 isn't a default? The main two main reasons we didn't just turn it on when written are: 1. New code in a pretty critical operation, needs to be tested a bunch first. 2. Lots of people would have installed packages without a reason set. ...both of which should be gone now, so we could turn it on by default in F18. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F18 DNF and history
On Fri, 2012-06-22 at 10:10 +0200, Nicolas Mailhot wrote: Le Jeu 21 juin 2012 14:23, Matej Cepl a écrit : On 19/06/12 15:33, Ales Kozumplik wrote: Thanks for pointing this out. I considered history a candidate for dropping because I didn't realize people had usecases for it. It is not present in the early versions of DNF but I will make sure to put it back in later. Especially in the situation we have broken dependencies (because we don't have Suggests/Recommends, but that's another issue, which I don't want to open now) we don't have quality uninstall á la aptitude (remove this package and all packages which were installed just to satisfy its requirements recursively) yum history undo is priceless in the situation when you want to try a package just to find out it brings 50MB of random crap. BTW if yum is being rewritten can we get a package downloader that sends the correct cache-control http headers to refresh data automatically instead of complaining metadata is wrong and aborting (for people behind a caching proxy)? Unique metadata was the, much better, solution to this problem. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F18 DNF and history
On 25/06/12 23:04, James Antill wrote: yumdb unset reason '*' Thanks ... results are interesting. Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F18 DNF and history
On 21/06/12 16:54, Michal Schmidt wrote: On 06/21/2012 04:27 PM, Nikola Pajkovsky wrote: Michal Schmidt mschm...@redhat.com writes: We do now. You can set clean_requirements_on_remove=1 in yum.conf in which version that is supported? Since 3.2.28-13 http://skvidal.wordpress.com/2010/11/09/orphaned-dep-cleanup-in-yum/ Mea culpa! I have missed we weren’t using the ‘reason’ info we’re now storing in the yumdb to know what is a dep and what is not which is a crucial piece of information. Then the curious minds ask ... why clean_requirements_on_remove = 1 isn't a default? Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F18 DNF and history
On 21/06/12 16:54, Michal Schmidt wrote: http://skvidal.wordpress.com/2010/11/09/orphaned-dep-cleanup-in-yum/ Is there some post-processing tool which would should me all packages for which there is no reason? Brief look at the source of packages-cleanup shows that --orphans isn't the one. Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F18 DNF and history
Le Jeu 21 juin 2012 14:23, Matej Cepl a écrit : On 19/06/12 15:33, Ales Kozumplik wrote: Thanks for pointing this out. I considered history a candidate for dropping because I didn't realize people had usecases for it. It is not present in the early versions of DNF but I will make sure to put it back in later. Especially in the situation we have broken dependencies (because we don't have Suggests/Recommends, but that's another issue, which I don't want to open now) we don't have quality uninstall á la aptitude (remove this package and all packages which were installed just to satisfy its requirements recursively) yum history undo is priceless in the situation when you want to try a package just to find out it brings 50MB of random crap. BTW if yum is being rewritten can we get a package downloader that sends the correct cache-control http headers to refresh data automatically instead of complaining metadata is wrong and aborting (for people behind a caching proxy)? -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F18 DNF and history
2012/6/22 Matej Cepl mc...@redhat.com: On 21/06/12 16:54, Michal Schmidt wrote: On 06/21/2012 04:27 PM, Nikola Pajkovsky wrote: Michal Schmidt mschm...@redhat.com writes: We do now. You can set clean_requirements_on_remove=1 in yum.conf in which version that is supported? Since 3.2.28-13 http://skvidal.wordpress.com/2010/11/09/orphaned-dep-cleanup-in-yum/ Mea culpa! I have missed we weren't using the 'reason' info we're now storing in the yumdb to know what is a dep and what is not which is a crucial piece of information. Then the curious minds ask ... why clean_requirements_on_remove = 1 isn't a default? +1 Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F18 DNF and history
Michał Piotrowski mkkp...@gmail.com writes: 2012/6/22 Matej Cepl mc...@redhat.com: On 21/06/12 16:54, Michal Schmidt wrote: On 06/21/2012 04:27 PM, Nikola Pajkovsky wrote: Michal Schmidt mschm...@redhat.com writes: We do now. You can set clean_requirements_on_remove=1 in yum.conf in which version that is supported? Since 3.2.28-13 http://skvidal.wordpress.com/2010/11/09/orphaned-dep-cleanup-in-yum/ Mea culpa! I have missed we weren't using the 'reason' info we're now storing in the yumdb to know what is a dep and what is not which is a crucial piece of information. Then the curious minds ask ... why clean_requirements_on_remove = 1 isn't a default? +1 I was asked myself, why it's not default behaviour of yum. -- Nikola -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
yum pragma: no-cache (was Re: F18 DNF and history)
From: Nicolas Mailhot nicolas.mail...@laposte.net can we get a package downloader that sends the correct cache-control http headers to refresh data automatically instead of complaining metadata is wrong and aborting (for people behind a caching proxy)? Have you tried changing http_caching option in yum.conf from (default) 'all' to 'packages'? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F18 DNF and history
On 19/06/12 15:33, Ales Kozumplik wrote: Thanks for pointing this out. I considered history a candidate for dropping because I didn't realize people had usecases for it. It is not present in the early versions of DNF but I will make sure to put it back in later. Especially in the situation we have broken dependencies (because we don't have Suggests/Recommends, but that's another issue, which I don't want to open now) we don't have quality uninstall á la aptitude (remove this package and all packages which were installed just to satisfy its requirements recursively) yum history undo is priceless in the situation when you want to try a package just to find out it brings 50MB of random crap. Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F18 DNF and history
On 06/21/2012 02:23 PM, Matej Cepl wrote: we don't have quality uninstall á la aptitude (remove this package and all packages which were installed just to satisfy its requirements recursively) We do now. You can set clean_requirements_on_remove=1 in yum.conf Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F18 DNF and history
Michal Schmidt mschm...@redhat.com writes: On 06/21/2012 02:23 PM, Matej Cepl wrote: we don't have quality uninstall á la aptitude (remove this package and all packages which were installed just to satisfy its requirements recursively) We do now. You can set clean_requirements_on_remove=1 in yum.conf in which version that is supported? -- Nikola -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F18 DNF and history
On 06/21/2012 04:27 PM, Nikola Pajkovsky wrote: Michal Schmidt mschm...@redhat.com writes: We do now. You can set clean_requirements_on_remove=1 in yum.conf in which version that is supported? Since 3.2.28-13 http://skvidal.wordpress.com/2010/11/09/orphaned-dep-cleanup-in-yum/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F18 DNF and history
On 21/06/12 16:07, Michal Schmidt wrote: On 06/21/2012 02:23 PM, Matej Cepl wrote: we don't have quality uninstall á la aptitude (remove this package and all packages which were installed just to satisfy its requirements recursively) We do now. You can set clean_requirements_on_remove=1 in yum.conf And what exactly does it? /me goes to reread Seth's blogpost, he dimly remembers he thought it isn't it when he read it first time. Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F18 DNF and history
On 06/19/2012 08:23 PM, Stephen John Smoogen wrote: Would it be helpful, if there was a list of extensively used options so that DNF knew what high notes it needed to hit sooner rather than later? Absolutely, I created a wiki page for it: https://github.com/akozumpl/dnf/wiki/Features-backlog Ales -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F18 DNF and history
Angus Salkeld asalk...@redhat.com writes: On 19/06/12 10:51 -0700, Adam Williamson wrote: On Tue, 2012-06-19 at 15:33 +0200, Ales Kozumplik wrote: On 06/19/2012 02:44 PM, Michał Piotrowski wrote: Hi, I have a question about DNF https://fedoraproject.org/wiki/Features/DNF Are there any plans to replace yum with dnf in the future? According to what is written here https://github.com/akozumpl/dnf/wiki/Features-Considered-for-Dropping history function will likely be dropped. From my POV history feature is very useful. Is there a plan to provide history function in Fedora dnf if yum gets dropped? Hi Michal, Thanks for pointing this out. I considered history a candidate for dropping because I didn't realize people had usecases for it. It is not present in the early versions of DNF but I will make sure to put it back in later. Just to add my voice to the choir, I use it extensively and I suspect many others in QA group too. It's extremely useful when trying to determine exactly what update caused a given problem. Maybe a yum history bisect would be a neat feature? nice one, sir -- Nikola -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F18 DNF and history
2012/6/20 Nikola Pajkovsky npajk...@redhat.com: Angus Salkeld asalk...@redhat.com writes: On 19/06/12 10:51 -0700, Adam Williamson wrote: On Tue, 2012-06-19 at 15:33 +0200, Ales Kozumplik wrote: On 06/19/2012 02:44 PM, Michał Piotrowski wrote: Hi, I have a question about DNF https://fedoraproject.org/wiki/Features/DNF Are there any plans to replace yum with dnf in the future? According to what is written here https://github.com/akozumpl/dnf/wiki/Features-Considered-for-Dropping history function will likely be dropped. From my POV history feature is very useful. Is there a plan to provide history function in Fedora dnf if yum gets dropped? Hi Michal, Thanks for pointing this out. I considered history a candidate for dropping because I didn't realize people had usecases for it. It is not present in the early versions of DNF but I will make sure to put it back in later. Just to add my voice to the choir, I use it extensively and I suspect many others in QA group too. It's extremely useful when trying to determine exactly what update caused a given problem. Maybe a yum history bisect would be a neat feature? nice one, sir Indeed. But this should be done on a RPM database copy - bisection should not leave any traces in the history. May be something like yum and git merge? # yum upgrade [...] # yum tag -a my_latest_stable_system # yum upgrade --enablerepo=updates-testing [..] something went wrong? # yum checkout my_latest_stable_system or # yum bisect start -- Nikola -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F18 DNF and history
On Wed, 2012-06-20 at 08:28 +1000, Angus Salkeld wrote: On 19/06/12 10:51 -0700, Adam Williamson wrote: On Tue, 2012-06-19 at 15:33 +0200, Ales Kozumplik wrote: On 06/19/2012 02:44 PM, Michał Piotrowski wrote: Hi, I have a question about DNF https://fedoraproject.org/wiki/Features/DNF Are there any plans to replace yum with dnf in the future? According to what is written here https://github.com/akozumpl/dnf/wiki/Features-Considered-for-Dropping history function will likely be dropped. From my POV history feature is very useful. Is there a plan to provide history function in Fedora dnf if yum gets dropped? Hi Michal, Thanks for pointing this out. I considered history a candidate for dropping because I didn't realize people had usecases for it. It is not present in the early versions of DNF but I will make sure to put it back in later. Just to add my voice to the choir, I use it extensively and I suspect many others in QA group too. It's extremely useful when trying to determine exactly what update caused a given problem. Maybe a yum history bisect would be a neat feature? I thought about implementing this, when I did yum history rollback the problem is that you can only go forwards. So say you have: # yum history list 4 up 3 up blah 2 up bar 1 up foo ...then a bisect looks like: # yum history list 5 rollback to 2 4 up 3 up blah 2 up bar 1 up foo # yum history list 6 2=1 or 2=3 5 rollback to 2 4 up 3 up blah 2 up bar 1 up foo ...etc. and it seemed like it'd be too horrible to live with that in the history. In theory we could add a feature so that when you are finished with the bisect you can remove or merge the history for all the transactions where the end rpmdb versions are the same. But it's not obvious that adding features to remove things from history is a good idea, in general. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F18 DNF and history
On 19 June 2012 14:44, Michał Piotrowski mkkp...@gmail.com wrote: According to what is written here https://github.com/akozumpl/dnf/wiki/Features-Considered-for-Dropping history function will likely be dropped. From my POV history feature is very useful. Is there a plan to provide history function in Fedora dnf if yum gets dropped? +1 I use it extensively on our test boxes with official packages and our custom repositories. --Simone -- You cannot discover new oceans unless you have the courage to lose sight of the shore (R. W. Emerson). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F18 DNF and history
On Tue, Jun 19, 2012 at 8:44 AM, Michał Piotrowski mkkp...@gmail.com wrote: Are there any plans to replace yum with dnf in the future? I imagine (and this is pure speculation) that in some perfect future, when dnf is considered mature, that it will probably be renamed to yum. In other words, I think this fork of yum is intended to eventually become the next version of yum. According to what is written here https://github.com/akozumpl/dnf/wiki/Features-Considered-for-Dropping history function will likely be dropped. From my POV history feature is very useful. Is there a plan to provide history function in Fedora dnf if yum gets dropped? I have no idea about that. -- Jared Smith -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F18 DNF and history
On 06/19/2012 02:44 PM, Michał Piotrowski wrote: Hi, I have a question about DNF https://fedoraproject.org/wiki/Features/DNF Are there any plans to replace yum with dnf in the future? According to what is written here https://github.com/akozumpl/dnf/wiki/Features-Considered-for-Dropping history function will likely be dropped. From my POV history feature is very useful. Is there a plan to provide history function in Fedora dnf if yum gets dropped? Hi Michal, Thanks for pointing this out. I considered history a candidate for dropping because I didn't realize people had usecases for it. It is not present in the early versions of DNF but I will make sure to put it back in later. Ales -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F18 DNF and history
2012/6/19 Ales Kozumplik akozu...@redhat.com: On 06/19/2012 02:44 PM, Michał Piotrowski wrote: Hi, I have a question about DNF https://fedoraproject.org/wiki/Features/DNF Are there any plans to replace yum with dnf in the future? According to what is written here https://github.com/akozumpl/dnf/wiki/Features-Considered-for-Dropping history function will likely be dropped. From my POV history feature is very useful. Is there a plan to provide history function in Fedora dnf if yum gets dropped? Hi Michal, Thanks for pointing this out. I considered history a candidate for dropping because I didn't realize people had usecases for it. Sometimes it happens that after large update you have something broken in your system. It's not always clear what could broke the system - then history function is very useful. It is not present in the early versions of DNF but I will make sure to put it back in later. Thank you very much. Ales -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Best regards, Michal http://eventhorizon.pl/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F18 DNF and history
On 06/19/2012 10:33 AM, Ales Kozumplik wrote: On 06/19/2012 02:44 PM, Michał Piotrowski wrote: Hi, I have a question about DNF https://fedoraproject.org/wiki/Features/DNF Are there any plans to replace yum with dnf in the future? According to what is written here https://github.com/akozumpl/dnf/wiki/Features-Considered-for-Dropping history function will likely be dropped. From my POV history feature is very useful. Is there a plan to provide history function in Fedora dnf if yum gets dropped? Hi Michal, Thanks for pointing this out. I considered history a candidate for dropping because I didn't realize people had usecases for it. It is not present in the early versions of DNF but I will make sure to put it back in later. Ales It is very useful indeed, at least for me. Germán. -- Germán A. Racca Fedora Package Maintainer https://fedoraproject.org/wiki/User:Skytux -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F18 DNF and history
On Tue, 2012-06-19 at 15:33 +0200, Ales Kozumplik wrote: On 06/19/2012 02:44 PM, Michał Piotrowski wrote: Hi, I have a question about DNF https://fedoraproject.org/wiki/Features/DNF Are there any plans to replace yum with dnf in the future? According to what is written here https://github.com/akozumpl/dnf/wiki/Features-Considered-for-Dropping history function will likely be dropped. From my POV history feature is very useful. Is there a plan to provide history function in Fedora dnf if yum gets dropped? Hi Michal, Thanks for pointing this out. I considered history a candidate for dropping because I didn't realize people had usecases for it. It is not present in the early versions of DNF but I will make sure to put it back in later. Just to add my voice to the choir, I use it extensively and I suspect many others in QA group too. It's extremely useful when trying to determine exactly what update caused a given problem. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F18 DNF and history
On 19 June 2012 11:51, Adam Williamson awill...@redhat.com wrote: On Tue, 2012-06-19 at 15:33 +0200, Ales Kozumplik wrote: On 06/19/2012 02:44 PM, Michał Piotrowski wrote: Hi, I have a question about DNF https://fedoraproject.org/wiki/Features/DNF Are there any plans to replace yum with dnf in the future? According to what is written here https://github.com/akozumpl/dnf/wiki/Features-Considered-for-Dropping history function will likely be dropped. From my POV history feature is very useful. Is there a plan to provide history function in Fedora dnf if yum gets dropped? Hi Michal, Thanks for pointing this out. I considered history a candidate for dropping because I didn't realize people had usecases for it. It is not present in the early versions of DNF but I will make sure to put it back in later. Just to add my voice to the choir, I use it extensively and I suspect many others in QA group too. It's extremely useful when trying to determine exactly what update caused a given problem. Would it be helpful, if there was a list of extensively used options so that DNF knew what high notes it needed to hit sooner rather than later? -- Stephen J Smoogen. The core skill of innovators is error recovery, not failure avoidance. Randy Nelson, President of Pixar University. Years ago my mother used to say to me,... Elwood, you must be oh so smart or oh so pleasant. Well, for years I was smart. I recommend pleasant. You may quote me. —James Stewart as Elwood P. Dowd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F18 DNF and history
On Tue, 2012-06-19 at 10:51 -0700, Adam Williamson wrote: On Tue, 2012-06-19 at 15:33 +0200, Ales Kozumplik wrote: On 06/19/2012 02:44 PM, Michał Piotrowski wrote: Hi, I have a question about DNF https://fedoraproject.org/wiki/Features/DNF Are there any plans to replace yum with dnf in the future? According to what is written here https://github.com/akozumpl/dnf/wiki/Features-Considered-for-Dropping history function will likely be dropped. From my POV history feature is very useful. Is there a plan to provide history function in Fedora dnf if yum gets dropped? Hi Michal, Thanks for pointing this out. I considered history a candidate for dropping because I didn't realize people had usecases for it. It is not present in the early versions of DNF but I will make sure to put it back in later. Just to add my voice to the choir, I use it extensively and I suspect many others in QA group too. It's extremely useful when trying to determine exactly what update caused a given problem. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net +1 - I too use the history function of yum quite a bit. -AdamM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F18 DNF and history
On Tue, 19 Jun 2012, Adam Miller wrote: On Tue, 2012-06-19 at 10:51 -0700, Adam Williamson wrote: On Tue, 2012-06-19 at 15:33 +0200, Ales Kozumplik wrote: On 06/19/2012 02:44 PM, Michał Piotrowski wrote: Hi, I have a question about DNF https://fedoraproject.org/wiki/Features/DNF Are there any plans to replace yum with dnf in the future? According to what is written here https://github.com/akozumpl/dnf/wiki/Features-Considered-for-Dropping history function will likely be dropped. From my POV history feature is very useful. Is there a plan to provide history function in Fedora dnf if yum gets dropped? Hi Michal, Thanks for pointing this out. I considered history a candidate for dropping because I didn't realize people had usecases for it. It is not present in the early versions of DNF but I will make sure to put it back in later. Just to add my voice to the choir, I use it extensively and I suspect many others in QA group too. It's extremely useful when trying to determine exactly what update caused a given problem. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net +1 - I too use the history function of yum quite a bit. And it is an absolutely critical component for sysadmin-side of things. Being able to quickly search to see when/who/what messed with pkg X makes tracking down changes a lot simpler. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F18 DNF and history
On 19/06/12 10:51 -0700, Adam Williamson wrote: On Tue, 2012-06-19 at 15:33 +0200, Ales Kozumplik wrote: On 06/19/2012 02:44 PM, Michał Piotrowski wrote: Hi, I have a question about DNF https://fedoraproject.org/wiki/Features/DNF Are there any plans to replace yum with dnf in the future? According to what is written here https://github.com/akozumpl/dnf/wiki/Features-Considered-for-Dropping history function will likely be dropped. From my POV history feature is very useful. Is there a plan to provide history function in Fedora dnf if yum gets dropped? Hi Michal, Thanks for pointing this out. I considered history a candidate for dropping because I didn't realize people had usecases for it. It is not present in the early versions of DNF but I will make sure to put it back in later. Just to add my voice to the choir, I use it extensively and I suspect many others in QA group too. It's extremely useful when trying to determine exactly what update caused a given problem. Maybe a yum history bisect would be a neat feature? -Angus -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
