DevHeads.net

F18 DNF and history

By =?ISO-8859-2?Q?... at 06/19/2012 - 08:44

Hi,

I have a question about DNF <a href="https://fedoraproject.org/wiki/Features/DNF" title="https://fedoraproject.org/wiki/Features/DNF">https://fedoraproject.org/wiki/Features/DNF</a>

Are there any plans to replace yum with dnf in the future?

According to what is written here
<a href="https://github.com/akozumpl/dnf/wiki/Features-Considered-for-Dropping" title="https://github.com/akozumpl/dnf/wiki/Features-Considered-for-Dropping">https://github.com/akozumpl/dnf/wiki/Features-Considered-for-Dropping</a>
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?

Comments

Re: F18 DNF and history

By Ales Kozumplik at 06/19/2012 - 09:33

On 06/19/2012 02:44 PM, Michał Piotrowski wrote:
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

Re: F18 DNF and history

By Matej Cepl at 06/21/2012 - 08:23

On 19/06/12 15:33, Ales Kozumplik wrote:
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

Re: F18 DNF and history

By Nicolas Mailhot at 06/22/2012 - 04:10

Le Jeu 21 juin 2012 14:23, Matej Cepl a écrit :
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)?

Re: F18 DNF and history

By James Antill at 06/25/2012 - 17:10

On Fri, 2012-06-22 at 10:10 +0200, Nicolas Mailhot wrote:
Unique metadata was the, much better, solution to this problem.

yum & "pragma: no-cache" (was Re: F18 DNF and history)

By Zdenek Pavlas at 06/22/2012 - 09:17

Have you tried changing http_caching option in yum.conf
from (default) 'all' to 'packages'?

Re: yum & "pragma: no-cache" (was Re: F18 DNF and history)

By Reindl Harald at 06/22/2012 - 09:22

Am 22.06.2012 15:17, schrieb Zdenek Pavlas:
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

Re: yum & "pragma: no-cache" (was Re: F18 DNF and history)

By Nicolas Mailhot at 07/02/2012 - 03:52

Le Ven 22 juin 2012 15:22, Reindl Harald a écrit :
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

Re: F18 DNF and history

By Michal Schmidt at 06/21/2012 - 10:07

On 06/21/2012 02:23 PM, Matej Cepl wrote:
We do now. You can set clean_requirements_on_remove=1 in yum.conf

Michal

Re: F18 DNF and history

By Matej Cepl at 06/21/2012 - 18:41

On 21/06/12 16:07, Michal Schmidt wrote:
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

Re: F18 DNF and history

By Nikola Pajkovsky at 06/21/2012 - 10:27

Michal Schmidt < ... at redhat dot com> writes:

in which version that is supported?

Re: F18 DNF and history

By Michal Schmidt at 06/21/2012 - 10:54

On 06/21/2012 04:27 PM, Nikola Pajkovsky wrote:
Since 3.2.28-13
<a href="http://skvidal.wordpress.com/2010/11/09/orphaned-dep-cleanup-in-yum/" title="http://skvidal.wordpress.com/2010/11/09/orphaned-dep-cleanup-in-yum/">http://skvidal.wordpress.com/2010/11/09/orphaned-dep-cleanup-in-yum/</a>

Re: F18 DNF and history

By Matej Cepl at 06/22/2012 - 04:02

On 21/06/12 16:54, Michal Schmidt wrote:
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

Re: F18 DNF and history

By James Antill at 06/25/2012 - 17:04

On Fri, 2012-06-22 at 10:02 +0200, Matej Cepl wrote:
You want the yumdb command in yum-utils. Eg.

yumdb unset reason '*'

Re: F18 DNF and history

By Matej Cepl at 06/25/2012 - 18:50

On 25/06/12 23:04, James Antill wrote:
Thanks ... results are interesting.

Matěj

Re: F18 DNF and history

By Matej Cepl at 06/22/2012 - 03:56

On 21/06/12 16:54, Michal Schmidt wrote:
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

Re: F18 DNF and history

By James Antill at 06/25/2012 - 17:09

On Fri, 2012-06-22 at 09:56 +0200, Matej Cepl wrote:
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.

Re: F18 DNF and history

By draco at 07/06/2012 - 13:44

On Mon, Jun 25, 2012 at 05:09:17PM -0400, James Antill wrote:
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.

Re: F18 DNF and history

By =?ISO-8859-2?Q?... at 06/22/2012 - 04:19

2012/6/22 Matej Cepl < ... at redhat dot com>:
+1

Re: F18 DNF and history

By Nikola Pajkovsky at 06/22/2012 - 06:32

Michał Piotrowski < ... at gmail dot com> writes:

I was asked myself, why it's not default behaviour of yum.

Re: F18 DNF and history

By Adam Williamson at 06/19/2012 - 13:51

On Tue, 2012-06-19 at 15:33 +0200, Ales Kozumplik wrote:
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.

Re: F18 DNF and history

By Angus Salkeld at 06/19/2012 - 18:28

On 19/06/12 10:51 -0700, Adam Williamson wrote:
Maybe a "yum history bisect" would be a neat feature?

-Angus

Re: F18 DNF and history

By James Antill at 06/20/2012 - 10:35

On Wed, 2012-06-20 at 08:28 +1000, Angus Salkeld wrote:
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.

Re: F18 DNF and history

By Nikola Pajkovsky at 06/20/2012 - 04:18

Angus Salkeld < ... at redhat dot com> writes:

nice one, sir

Re: F18 DNF and history

By =?ISO-8859-2?Q?... at 06/20/2012 - 04:31

2012/6/20 Nikola Pajkovsky < ... at redhat dot com>:
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

Re: F18 DNF and history

By Adam Miller at 06/19/2012 - 15:07

On Tue, 2012-06-19 at 10:51 -0700, Adam Williamson wrote:
+1 - I too use the history function of yum quite a bit.

-AdamM

Re: F18 DNF and history

By Seth Vidal at 06/19/2012 - 15:19

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

Re: F18 DNF and history

By Stephen John Smoogen at 06/19/2012 - 14:23

On 19 June 2012 11:51, Adam Williamson < ... at redhat dot com> 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?

Re: F18 DNF and history

By Ales Kozumplik at 06/20/2012 - 03:58

On 06/19/2012 08:23 PM, Stephen John Smoogen wrote:
Absolutely, I created a wiki page for it:

<a href="https://github.com/akozumpl/dnf/wiki/Features-backlog" title="https://github.com/akozumpl/dnf/wiki/Features-backlog">https://github.com/akozumpl/dnf/wiki/Features-backlog</a>

Ales

Re: F18 DNF and history

By =?ISO-8859-1?Q?... at 06/19/2012 - 09:44

On 06/19/2012 10:33 AM, Ales Kozumplik wrote:
It is very useful indeed, at least for me.

Germán.

Re: F18 DNF and history

By =?ISO-8859-2?Q?... at 06/19/2012 - 09:41

2012/6/19 Ales Kozumplik < ... at redhat dot com>:
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.

Thank you very much.

Re: F18 DNF and history

By Jared K. Smith at 06/19/2012 - 09:12

On Tue, Jun 19, 2012 at 8:44 AM, Michał Piotrowski < ... at gmail dot com> wrote:
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.

I have no idea about that.

Re: F18 DNF and history

By Simone Caronni at 06/19/2012 - 08:48

On 19 June 2012 14:44, Michał Piotrowski < ... at gmail dot com> wrote:
+1

I use it extensively on our test boxes with official packages and our
custom repositories.

--Simone