Hi

Have such task: packaging software into S. package. For proper functionality this software requires modification of some(for now only one) existing config file(s) in system. Well, I can do it in install/doinst.sh, this will not cause any problem for me. BUT, I need a way to revert that modification when removing package. AFAIK, there is no predefined uninstall routines for S., but I do not want to keep those trash. Any ideas?

Predicting question: no, file I want to modify is single solid file, and cannot be split into family of *.d-s

I would do what they often do on SBo. Don't modify the system file(s) but rather include a README that tells the user how to manually change the system so that the application in question will run.

1 members found this post helpful.

Exactly which file needs to be altered and why?

Letting an auto-tool do configuration modifications without asking is a Bad Idea(tm) most times.

Options you have:
> The Readme Option: You include the relevant information in a README file so the end user can adapt the software to his needs.
> The SuperScript option: You code an Install script that asks clever questions during the install of the package, makes configurations as needed and creates a backup of the modified configurations just in case. Think of Debian's package configuration system. It seems a lot of worth for so little gain and still having a decent chance of having the system broken.

Installation of software should not turn itself on. For user programs, they do not run until the user takes the action to run them. Daemons should not run unless the user, owner, or administrator starts them. They should not run at boot up time unless the user, owner, or administrator enabled that. Changing the configuration of some other program or the system sounds wrong. Can you explain what that change is and what is changed?

Maybe what you can do is provide a program the user can run to make the change, along with documentation (a README file, a man page) that tells them what the program will do (needs to be detailed enough that the person could do it themselves, instead).

@ruario
> ...but rather include a README that tells the user how...
Sure I shall do it, but I want to short as much manual setting/editions as possible(it already has more than a lot).

> Exactly which file needs to be altered and why?
Well, it is "/etc/inittab", because only it can Obviously, when removing package I must somehow remove such entries. But how?

@BlackRider
> The SuperScript option:
pkgtools not designed to ask questions during installation of packages, especially during distribution installation.

@Skaperen
> Installation of software should not turn itself on.
It will not, I promise

Ouch!

Now you bring the matter, I would like to give it a try in a testing environment.

I would have doinst.sh copy the existing inittab to inittab.new and then make its modifications to the new file. The sysop then would have the option of substituting the .new for the original.

@saulgoode
doinst.sh of package1 does copy inittab -> inittab.new, modifies .new file
doinst.sh of package2 does copy inittab -> inittab.new(overwriting that one made by package1), modifies .new file
...
the same for each n-th package
As a result we have inittab.new suitable only for last installed package(in case of bulk installation).
In any case, this is offtopic, because there is no any problem modifying inittab(OR any other file) during installation, but problem reverting that modification during uninstallation.

Since removepkg does not support any sort of postrm or prerm action, then you have no way to implement such a feature other than some wild hack.

That's where putting all the steps in a script can help. The README can limit itself to describing what the user or administrator needs to know or do or provide.

That's fine as long as this is done only by user/administrator choice. An enable script and a disable script could do the job. And run that script when the package is to be uninstalled. The script can do something like this:==
Those questions should be in the enable script. They should be few, but sometimes packages must know certain things.

Good