Suppose that you have a custom package gimp-unstable-2.7, that is not
known to your vendor system. You want to follow updates, but once
gimp-2.8 appears, you want your package silently replace by a stable
distro package.
Or suppose that you created libfoo-mybranch-2.3, that contains an
important
On Thu, 3 Sep 2009, Stanislav Brabec wrote:
Suppose that you have a custom package gimp-unstable-2.7, that is not
known to your vendor system. You want to follow updates, but once
gimp-2.8 appears, you want your package silently replace by a stable
distro package.
Or suppose that you created
Seth Vidal wrote:
libfoo-mybranch.spec:
Version:2.3
Provides: libfoo = %{version}
ObsoleteBy: libfoo = 2.4
What do you think about such feature?
What does this get you that isn't already handled by 'Obsoletes'?
If you're introducing a pkg later why not put 'Obsoletes' in
I believe conflicts has been used for this purpose in the past. While it's not
an automatic replacement, it does alert the admin to remove the custom package,
and replace it with the distro package that is conflicting.
--Mark
Stanislav Brabec wrote:
Seth Vidal wrote:
libfoo-mybranch.spec:
On 09/03/2009 05:56 PM, Stanislav Brabec wrote:
Mark Hatle wrote:
I believe conflicts has been used for this purpose in the past. While it's not
an automatic replacement, it does alert the admin to remove the custom package,
and replace it with the distro package that is conflicting.
It does
Ralf Corsepius wrote:
Also, what do you imagine to happen with your
ObsoletesBy: foo 2.4
if the prediction of foo to replace your package doesn't apply?
You will have to prepare an update of libfoo-mybranch, that contains new
ObsoletedBy. You may even prepare a (nearly) empty package.
