Re: further package removals/potential package removals

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

 



Arjan van de Ven wrote:

Meanwhile, new packaging for, say, nautilus which has
   Requires(missingok): gnome-vfs2-smb
and a depsolver that tests RPMSENSE_MISSINGOK drop a sub-tree that
is optional.

I fail to see a mulberry bush, except in this loopy and endless fretting.

Show me the mulberries *please*.




user goes from package-1.0-1.0 to package-1.1-1.0 which now had a
Requires(missingok): gnome-vfs2-smp. Fine; yum (for the sake of
argument) grabs gnome-vfs2-smp as well and everything is happy.
Now the user gets annoyed by the "bloat" and removes gnome-vfs2-smp.
Still fine.

Then a security update comes out, package-1.1-1.1 and the user of course
upgrades to that. yum will *AGAIN* pull in gnome-vfs2-smp. User gets
really annoyed and considers this not-fine.

Would there be a way to version the missingok such that it's a hint to
the depsolver to only solve the dep if the old package is matching the
versioning ?



The "missingok" bit is passed to yum. Yum can of course choose to treat the "missingok" dependency as a mandatory Requires:, in which case the beahavior is as you describe.

Or yum, and anaconda, and up2date might perhaps do something more intelligent.

You never know, do ya?

73 de Jeff


[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