Hi Yan ;-) Bob Proulx (bob@xxxxxxxxxx) wrote: > Yan Fitterer wrote: > > I have a file that conflicts with an already-installed version that's > > part of another package. > > > I want to include the file, but not if it is there already. I need as > > well to make sure the dependency is listed, even if my package doesn't > > own the file. Some more context would be useful. Will your version of the file be identical to the one from the other rpm? If the other rpm is not there, could it potentially get installed after yours gets installed? If the contents are different which do you want to take preference during an upgrade/install of either? It's an odd requirement and there might be another approach which is better. > But in this case I think you must require a newer version of the other > package and both you and it must coordinate somehow on sharing this > file. Yes the best chance of success is probably if the other rpm is cooperates with yours. But most likely you have no control over the other rpm - I'm guessing that the other rpm is from a vendor? > > I could as well move it out of the way in %pre and restore it in %post, > > but that wouldn't be right either... > > The problem with doing it that way is that then the other package will > fail --verify. That is not good. That would cause people like me to > reinstall the first package in order to correct that problem. Actually I think that is the best option - there are ways of doing the restore and still preserving mtime etc. in the inode. You could probably hack it together with GNU touch although there are utilities around specifically for doing this; I forget what they are but I remember seeing them in a script kiddie's rootkit once. If you want rpm -qf $file to return both your rpm and the other one, of course you'll need $file installed into the buildroot during %install and listed in the %files section. > And what happens when the first package is upgraded? That will again > replace that file that was moved out of the way in the %pre so that > does not work there either. I don't see the problem here, other than that the upgrade will require a --replacefiles. I think that's unavoidable, since that stage of the upgrade will need to complete before any triggers you might set up from your rpm to the other, thereby preventing you from using triggers to preempt the upgrade. -- ## Adam Spiers ## musician & hacker ## me@xxxxxxxxxxxxxx ## http://tigerpig.org $@=>$_=q^*{$Just =bless{},'$another ';"\$Perl \::$hacker,"}=sub{print$%[$.++];$ },eval join+v45.62,(q)$q ))x v54^,s.(?<=\$)\w*[\s,].f if+push@%,$&.sixmegs,eval _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
