Another issue to consider is what happens when the package that originally owned the file updates itself. More than likely your changes will be removed and the package will reclaim ownership of the file.
At one time I did use SuSEconfig scripts to make sure these files maintained the changes I wanted. However this introduced other problems so eventually I abandoned this tactic and have submitted to what is given to the user by default. It would be nice if there was a way that Enterprises could more easily incorporate some of these things that you are talking about. Jared J. >>> On Tue, Jan 8, 2008 at 3:58 PM, in message <[EMAIL PROTECTED]>, Thorsten Kukuk <[EMAIL PROTECTED]> wrote: > On Tue, Jan 08, Dan Stromberg wrote: > >> We have about 1.5 dozen files (EG inittab) that are owned by openSUSE >> and SLES, and also owned by an RPM that holds our product. >> >> I gather this is generally considered poor practice - just how bad is it? > > Very simple: the result is undefined. This works as long as this files > are identical. If they are not, you don't know which version will win. > >> If we install the OS, install our product, then remove our product, are >> we in for losing those OS files? Will the changes be reverted (I'm >> guessing they won't be reverted)? > > I don't know if this files will be removed, I would expect that your > files will stay. But they will not be reverted to the OS one. > >> What if we never uninstall it? It would seem to violate the principle >> of least surprise to have an RPM you should "just never uninstall", but >> is there more to it than that? > > I don't see a difference here, at least after the next update of such a > package, it depends on the flags of this files which will "win" and be there > afterwards. It does not need to be your version, could very well be the > OS one, even if your application will not be uninstalled. > >> What if we had our RPM's make algorithmic changes to files like inittab >> instead of trying to own the files, and then have those same RPM's >> attempt to algorithmically revert the changes on rpm deletion - would >> that leave us in the same situation as having two RPM's owning a given >> file? I'm guessing not, but I'd like to make sure we cover all the bases. > > This will be a correct solution. > > Thorsten --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
