[Yum-devel] [dnf] new build: dnf-0.3.2-1

Ales Kozumplik akozumpl at redhat.com
Tue Apr 9 08:53:45 UTC 2013


On 04/08/2013 08:59 PM, James Antill wrote:
> On Mon, 2013-04-08 at 20:33 +0200, Aleš Kozumplík wrote:
>> Hello,
>>
>> dnf-0.3.2-1 is in Rawhide and F19 testing updates[1] since today.
> [...]
>> Handling of per-repo package exclusions was fixed and clarified. DNF
>> respects excludes for all operations, not just for update and install as
>> Yum does[2], I find this more intuitive.
>
>   So you mean you added the excludes logic to installed packages, as well
> as available ones. Out of curiosity, when you do:
>
> dnf -x foo upgrade
>
> ...are the rpmdb versions correct? What happens if foo is obsoleted?
> What about if foo conflicts/obsoletes some package you are installing?
> What about if foo requires some package that is going away due to the
> upgrade?

It's all basically the same thing as in the Seth's case: the version is 
locked and excluding a package by a user shouldn't break any dependency 
constrains. By excluding a package we only say: no matter what this 
package shouldn't appear in a transaction/change version and we don't 
want to see it in list/info outputs.

>   What does "dnf -x foo check" say?

'check' is not yet supported by DNF (and strangely nobody complains), 
but it wouldn't report it as a broken dep: it is still in the rpmdb. 
Thinking about it, 'check' could be a good candidate to turn off 
excludes all together, but it mainly depends on what people use 'check' for.

>
>   I'm also kind of curious about how many users who do a global config.
> of something like exclude=kernel, never want to be able to see the
> installed kernel packages unless they use --disableexcludes (or never if
> they are using PK, I guess).

It's all about a tradeoff. Either they can be confused they don't see 
kernel after they excluded it or be confused they can see it yet can't 
upgrade it. My take is that excluding on all commands is more consistent.


>   You should also add a note that dnf excludes are name only currently
> (at least the code implies that), although that might be a feature as
> otherwise it might be hard to make sure someone doesn't do
> "dnf -x foo-1.1.1 install foo" when foo-1.1.2 is available.

Both the dnf(8) and dnf.conf(8) say so. Out of curiosity: if one 
excludes a particular NVR in yum and then upgrades the package by name, 
does the exclude version apply to the updating or the updated package?

Ales


More information about the Yum-devel mailing list