3 ms·

I have other bits of software that manage that part for me, as part of my automation. Why would I expect a package manager to also restart my services? I need

I have other bits of software that manage that part for me, as part of my automation. Why would I expect a package manager to also restart my services? I need to make sure that other parts of the stack can either handle that service going away gracefully, or have automation around it, my package manager can't know the dependencies in which certain services should be stopped/started for example to allow for graceful failover. It's illogical to try and place all of that logic in the package manager, that is not its job. Especially if there are other config changes that need to happen too that are not part of that package management system. Humans can still be out of the picture without a package manager starting/stopping/restarting services. Your suggestion of it being part of a maturity model don't make sense. I asked for the package to be upgraded, not for the service to be restarted.

Annatar 9y ago
Doing it through the package manager presents a uniform interface through one single command. Executing ordinary shell scripts through the package’s postinstall minimizes dependencies (no Puppet, Chef or CFengine required) and makes it easier on system administrators who do not have to learn any of those applications to perform system maintenance or perform telemetry gathering as directed by system engineering department. Doing or calling configuration scripts inside of OS packaging ensures that the system knows about and can be queried through its standardized software management subsystem as to what has been done to it, where, and by whom (component owner will be in the package metadata). For example: a package delivers /opt/abcd/sbin/pgadm, which would be your engineered command line interface to CREATE DATABASE, database backups, and so on; then the application-db package calls that in its postinstall to create a database specific to that application. Best of all, once one has such packages, they can be plugged into Kickstart, JumpStart, AutoYaST, or whatever the OS provides for automated provisioning and hardware whether physical or virtual, turned into fully configured systems from literally nothing with no special or custom provisioning required. You could lose entire networks of servers and prop them up in seconds again this way.

Annatar 9y ago

Doing it through the package manager presents a uniform interface through one single command. Executing ordinary shell scripts through the package’s postinstall minimizes dependencies (no Puppet, Chef or CFengine required) and makes it easier on system administrators who do not have to learn any of those applications to perform system maintenance or perform telemetry gathering as directed by system engineering department. Doing or calling configuration scripts inside of OS packaging ensures that the system knows about and can be queried through its standardized software management subsystem as to what has been done to it, where, and by whom (component owner will be in the package metadata). For example: a package delivers /opt/abcd/sbin/pgadm, which would be your engineered command line interface to CREATE DATABASE, database backups, and so on; then the application-db package calls that in its postinstall to create a database specific to that application. Best of all, once one has such packages, they can be plugged into Kickstart, JumpStart, AutoYaST, or whatever the OS provides for automated provisioning and hardware whether physical or virtual, turned into fully configured systems from literally nothing with no special or custom provisioning required. You could lose entire networks of servers and prop them up in seconds again this way.