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?
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)?
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?
What if we do an upgrade of our product RPM's - could trouble ensue there with two RPM's owning a file?
I might prefer to move the tweaks to these system files into a shell script (outside an RPM) as part of our OS installer (via autoyast), but it's not entirely up to me.
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.
Oh, and are "application installation scripts" going the way of the dodo now that rpm's and deb's and pkg's are taking off?
Thanks!
--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
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
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 20080108225849.GA11522@suse.de,
Thorsten Kukuk kukuk@suse.de 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: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 2008-01-08 13:55:04 -0800, 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?
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)?
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?
What if we do an upgrade of our product RPM's - could trouble ensue there with two RPM's owning a file?
I might prefer to move the tweaks to these system files into a shell script (outside an RPM) as part of our OS installer (via autoyast), but it's not entirely up to me.
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.
Oh, and are "application installation scripts" going the way of the dodo now that rpm's and deb's and pkg's are taking off?
why do you need such overlaps at all?
darix
Marcus Rueckert wrote:
On 2008-01-08 13:55:04 -0800, 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?
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)?
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?
What if we do an upgrade of our product RPM's - could trouble ensue there with two RPM's owning a file?
I might prefer to move the tweaks to these system files into a shell script (outside an RPM) as part of our OS installer (via autoyast), but it's not entirely up to me.
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.
Oh, and are "application installation scripts" going the way of the dodo now that rpm's and deb's and pkg's are taking off?
why do you need such overlaps at all?
darix
We may not not need dual file ownerships. In fact, I believe we don't.
We want to automate our install as much as possible, and some here believe that rpm is the right way to automate it, including rpm file dual ownership.
For example, we want to throw a getty on ttyS0 - for that we need to change /etc/inittab. The approach so far has been to replace /etc/inittab. I'm now trying to gently pitch changing it from a post and postun.
--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
hi,
autoyast kiwi
i would rather investigate those instead of doing those rpm hackery
darix
On Mittwoch, 9. Januar 2008 19:01:27 Dan Stromberg wrote:
We want to automate our install as much as possible, and some here believe that rpm is the right way to automate it, including rpm file dual ownership.
For example, we want to throw a getty on ttyS0 - for that we need to change /etc/inittab. The approach so far has been to replace /etc/inittab. I'm now trying to gently pitch changing it from a post and postun.
I would prefer autoyast, but I like to show you two other possible options:
Alternatively, you can add the files as "normal" files in the filelist of your package (without %config) - So they're no config files any longer and would not be updated by the original RPM. But this also implements, that user changes are lost if you update _your_ package. (You can perhaps fix this in the %pre and %post with md5sum comparison or something else -- re-implement the wheel...) => ugly, but works for config files ;-)
Or try to re-package the rpms you need containing "your" settings. This means: * watch for updates of the main package (and rebuild your own) * import your own gpg-key to the user machine
Regards, Lars --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Wed, 9 Jan 2008, Dan Stromberg wrote:
We may not not need dual file ownerships. In fact, I believe we don't.
We want to automate our install as much as possible, and some here believe that rpm is the right way to automate it, including rpm file dual ownership.
For example, we want to throw a getty on ttyS0 - for that we need to change /etc/inittab. The approach so far has been to replace /etc/inittab. I'm now trying to gently pitch changing it from a post and postun.
and in the case of /etc/inittab it will be the best way to modify it (instead of just plainly replacing the file).
This file is marked as %config(noreplace) in the package owning it (in this case aaa_base) so you are indeed pretty safe from your changes being overwritten by a possible aaa_base update.
Putting this the other way around: if the need arises to frequently touch some system-owned files, it may make sense to either get the distribution to support your local changes, maybe even controlled by some sysconfig variable or similar or get the distribution to mark that file as %config(noreplace) in the owning package.
But both of these approaches have their issues and can not always be taken. For example if a config file in a package changes from time to time (because of upstream), a %config(noreplace) would prevent updating users from getting the new configuration, which may even be needed for proper operation of a certain given package ...
Hello,
On Jan 9 10:01 Dan Stromberg wrote (shortened):
We want to automate our install as much as possible, and some here believe that rpm is the right way to automate it, including rpm file dual ownership.
For example, we want to throw a getty on ttyS0 - for that we need to change /etc/inittab. The approach so far has been to replace /etc/inittab. I'm now trying to gently pitch changing it from a post and postun.
Blindly replace whatever config file could be destructive.
Think about when the admin has changed it intentionally according to his special needs. Think about the mess when several different packages would blindly replace a particular config file.
For example at least I would be upset if your package just replaces my /etc/inittab so that I may get back our default runlevel 5 because I have intentionally set runlevel 3. Business server admins may even like to kill you ;-) if unexpectedly a special server just boots into runlevel 5 which could happen weeks or months later after your package blindly replaced their special sophisticated /etc/inittab when the server doesn't need a reboot for a longer time.
To be on the safe side: First of all test if the content of the config file is what you expect (e.g. test if there is already a getty on ttyS0 and if yes, test if it is the right one for your package and if not don't blindly overwrite it). Only if the content is o.k., make first of all a backup (e.g. something like /etc/inittab.<your-package-name>.save) and then finally try to change it in a transaction (i.e. have all-or-nothing semmantics) so that there can never be any inconsistent content in /etc/inittab e.g. via cp -p /etc/inittab /etc/inittab.your-package-name.save \ && cp -p /etc/inittab /etc/inittab.your-package-name \ && sed -i -e '...' /etc/inittab.your-package-name \ && mv -f /etc/inittab.your-package-name /etc/inittab \ || mv -f /etc/inittab.your-package-name.save /etc/inittab
Kind Regards Johannes Meixner
-
Dan Stromberg -
Jared Jensen -
Johannes Meixner -
Lars Vogdt -
Marcus Rueckert -
Ruediger Oertel -
Thorsten Kukuk