4 ms·

You might find this a problematic approach: - You make packages track more state―“stuff has changed”―and if there are no triggers, you can't even set a flag fo

by aasasd 7y ago

You might find this a problematic approach: - You make packages track more state―“stuff has changed”―and if there are no triggers, you can't even set a flag for the package's runtime: instead, you have to paranoically check for changes at the run time and compute the difference. Meanwhile, an installer/updater knows exactly that something was changed, and what precisely it was―because the installer just done that. - You're shifting work from install time to run time, which e.g. in backend web programming is exactly the opposite of the right thing to do. Because modifications, in most cases, occur much more rarely than usage, and because making the user wait is a no-no. So, an admin who wants to prepare installed packages for the use, would have to patch the ‘trigger’ stage back in, via their scripts or something―with the caveat that they can't pause the installation in the meantime, so that all changes are processed before the updated programs are run.

secure 7y ago
> Meanwhile, an installer/updater knows exactly that something was changed, and what precisely it was―because the installer just done that. Except the distri installer does not modify files, it only ever adds images to the package store (which, to be fair, might result in changes to the contents of exchange directories, which are derived from the package store contents). I agree with the larger point that state tracking might be hard, but it’s not clear to me that it would be easier in distri’s architecture if the installer was responsible for it. > You're shifting work from install time to run time, which e.g. in backend web programming is exactly the opposite of the right thing to do Absolutely. My observation here is that I always want to shift that work. Frequently, I had to wait for extra work to finish that was entirely unrelated to what I wanted to accomplish. E.g., if you don’t update your Debian machine for a few weeks and want to install a new package, maybe that requires a libc update, which requires service restarts, etc. I wanted to explore whether shifting the work improves my experience, and so far it does.
- aasasd 7y ago
  > the distri installer does not modify files, it only ever adds images to the package store The set of installed packages also comprises state of the system. It's the same as in OOP: modification of data in objects is equivalent to a function accepting prior state and outputting an updated state—only it's more difficult to track the changes when they're done from the inside and/or in a far-reaching manner of OOP. So, in this example, known changes on the installer's level would encompass the installed/updated packages, leaving determining file-level changes to setup scripts of each package. I guess different strategies may exist, but pretty sure this is approximately what other package managers do. > if you don’t update your Debian machine for a few weeks and want to install a new package, maybe that requires a libc update, which requires service restarts, etc. Afaik, if you don't restart services, you can run into incompatibilities between old and updated libraries at the runtime of a service. Suppose I'm running a web server in e.g. Python, and I happen to call a script for the first time after such an update. The script loads an extension which relies on freshly updated libc (for example), while the server has the old one loaded. In short, the system also has state in memory, which after an update differs from the state on the disk—and using mismatching parts of those two is not advisable. I'm not even sure what would happen in C-level libs in this case (“symbol missing” probably?), but I guess everyone lived through mismatched parts of code at the level of scripting languages, and the result is usually an exception. If you catch this situation at the update time, you can gracefully restart the web server while handing new requests to the newly-started instance. If you bump into it at the run time, that's an error for at least one client.

by aasasd 7y ago

secure 7y ago

> Meanwhile, an installer/updater knows exactly that something was changed, and what precisely it was―because the installer just done that. Except the distri installer does not modify files, it only ever adds images to the package store (which, to be fair, might result in changes to the contents of exchange directories, which are derived from the package store contents). I agree with the larger point that state tracking might be hard, but it’s not clear to me that it would be easier in distri’s architecture if the installer was responsible for it. > You're shifting work from install time to run time, which e.g. in backend web programming is exactly the opposite of the right thing to do Absolutely. My observation here is that I always want to shift that work. Frequently, I had to wait for extra work to finish that was entirely unrelated to what I wanted to accomplish. E.g., if you don’t update your Debian machine for a few weeks and want to install a new package, maybe that requires a libc update, which requires service restarts, etc. I wanted to explore whether shifting the work improves my experience, and so far it does.

aasasd 7y ago
> the distri installer does not modify files, it only ever adds images to the package store The set of installed packages also comprises state of the system. It's the same as in OOP: modification of data in objects is equivalent to a function accepting prior state and outputting an updated state—only it's more difficult to track the changes when they're done from the inside and/or in a far-reaching manner of OOP. So, in this example, known changes on the installer's level would encompass the installed/updated packages, leaving determining file-level changes to setup scripts of each package. I guess different strategies may exist, but pretty sure this is approximately what other package managers do. > if you don’t update your Debian machine for a few weeks and want to install a new package, maybe that requires a libc update, which requires service restarts, etc. Afaik, if you don't restart services, you can run into incompatibilities between old and updated libraries at the runtime of a service. Suppose I'm running a web server in e.g. Python, and I happen to call a script for the first time after such an update. The script loads an extension which relies on freshly updated libc (for example), while the server has the old one loaded. In short, the system also has state in memory, which after an update differs from the state on the disk—and using mismatching parts of those two is not advisable. I'm not even sure what would happen in C-level libs in this case (“symbol missing” probably?), but I guess everyone lived through mismatched parts of code at the level of scripting languages, and the result is usually an exception. If you catch this situation at the update time, you can gracefully restart the web server while handing new requests to the newly-started instance. If you bump into it at the run time, that's an error for at least one client.