Re: dnf-0.4.11

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



from a developers point of view the current behavior is clear and perfect
"what is not enabled is handeled as it would not exist"

means:
repos with "enabled=0" are completly ignored until --enablrepo with no
but and if - clear and straight logical decision

from a users point of view "all" has a different meaning

well, i can live with both because i am developer and i know
how these things are working, i know that the codebase is much
cleaner the way it works currently

personally i would draw the line in case if it is my code and act
like the user expects it, not in general, but in that case of
"meaningless" data which are refreshed and no bad impact if lost

Am 12.01.2014 22:57, schrieb Alec Leamas:
> I have come to understand that for yum, commands like clean only applies to the actual buildroot. So without a -r
> argument, the cleaning is done on the default root, whatever this might be(?).
> 
> Actually, there is probably nothing wrong with this - it works fine when using the -r option. Problems comes
> without it, when one thinks it applies to all buildroots. It would perhaps make sense outputting something like
> "Using buildroot foo" when there is no -r on the command line(?).
> 
> 
> 
> On Sun, Jan 12, 2014 at 10:47 PM, Reindl Harald <h.reindl@xxxxxxxxxxxxx <mailto:h.reindl@xxxxxxxxxxxxx>> wrote:
> 
> 
>     Am 12.01.2014 22:42, schrieb Miroslav Suchy:
>     > On 01/12/2014 08:27 PM, Reindl Harald wrote:
>     >> "dnf clean all" without "dnf --enablerepo=updates-testing clean all" does
>     >> exactly *nothing*  in case of "updates-testing", the same for YUM simply
>     >> because folders of non-enabled repos are not relevant for any operation
>     >
>     > And is this correct behavior? (and yum behaves same way, so same question apply to yum as well).
> 
>     no, i only explained the current state of play
> 
>     looking at the word "all" and it's meaing clearly *no*
>     looking at the thread and result of the behavior clearely *no*
>     looking at that people use "updates-testing" with --enablerepo *no*
>     looking at the fact that i do not trust the word "all" clearly *no*
> 
>     > Man page for yum state:
>     >
>     > yum clean metadata
>     > Eliminate  all  of the files which yum uses to determine the remote availability of packages. Using this option
>     > will force yum to
>     > download all the metadata the next time it is run.
>     >
>     > There is no statement that it apply only for *currently enabled* repository.
>     > I would expect that it clean *all* metadata.
>     >
>     > I was recently very surprised that when I done :
>     >
>     > # rpm -q yum
>     > yum-3.4.3-128.fc20.noarch
>     > # yum clean all
>     > ...
>     > # du -sh /var/cache/yum/x86_64/*
>     > 225M    /var/cache/yum/x86_64/19
>     > 111M    /var/cache/yum/x86_64/20
>     > 406M    /var/cache/yum/x86_64/rawhide
>     >
>     > that there is a lot of data in /var. To be precise - after this operation I would expect that
>     > /var/cache/yum/x86_64/ would have zero size. And not 730 MB.
> 
>     and that is why i switched 7 years ago to "rm -rf /var/cache/yum*"

Attachment: signature.asc
Description: OpenPGP digital signature

-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux