Steve Dickson napsal(a):
Adam Tkac wrote:
Steve Dickson napsal(a):
I'm looking for a little help with a potential messy update.
Basically, a configuration file is been moved from one package
to another, dependent, package. So if the package that contains
the old config file is not completely removed when the package
with the new config file is installed, there will be file
conflict....
Now here is the context
nfs-utils-lib-1.0.8-9 moving to nfs-utils-lib-1.0.8-10
nfs-utils-1.0.10-7 moving to nfs-utils-1.1.0-1
nfs-utils depends on nfs-utils-lib
nfs-utils-1.0.10-7 contains the obsolete config file
nfs-utils-lib-1.0.8-9 contains the new config file
So when nfs-utils-lib upgraded there a file confliction
because the file already exists in nfs-utils-1.0.10-7.
Now if you force install nfs-utils-lib-1.0.8-10 or
remove nfs-utils then install nfs-utils-lib-1.0.8-10
then things work...
So is there some rpm spec file magic I can to make
this work? Is there a way to remove a package for
another one is installed? Are force upgrades an option?
tia,
steved.
--
Fedora-maintainers mailing list
Fedora-maintainers@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-maintainers
I believe that rpm triggers should help you
(http://archive.rpm.org/support/RPM-Changes-6.html). You could try
something like this in new version of nfs-utils-lib:
%triggerin -- nfs-utils <= 1.0.10-7
rm -f _configfile_
Good idea... but.. if I remove/rename the config file, by hand,
before the nfs-utils upgrade, it still complains about the
file confliction. I guess RPM has some time of file registry
for each package.
So looks like you have to use Conflicts directive in specfile (same as
Requires,
in nfs-utils use for example Conflicts: nfs-utils-lib < 1.0.8-9
in nfs-utils-lib use Conflicts: nfs-utils < 1.1.0-1)
This cause that packages have to be updated simulateously. If this still
doesn't help I don't have any next ideas :(
But I recommend you test improved script before you make final build :)
Is there such an thing as a "final" build?? 8-)
I call version which is generally avaliable as "final" :)
Adam
--
Fedora-maintainers mailing list
Fedora-maintainers@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-maintainers
--
Fedora-maintainers-readonly mailing list
Fedora-maintainers-readonly@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
