You can, if the community wants to go in that direction.
Ideally the software which loads "plugins.xml" is updated to support a conf.d-like directory full of "plugin-pkg1.xml" through "plugin-pkgN.xml", each owned by separate packages. Many OSS projects have done this.
If that's not possible (closed-source, too much work, whatever) then it seems simple enough to build a separate XML-merging tool that the package manager invokes which combines the separate XML files during package installation.
Which is fine and all, but don't expect users to flock to your distribution that doesn't support $SOFTWARE because you decided they do things wrong.
Honestly: the defence of shit software and user-hostile developers never ceases to amaze me.
This need not be an automatic action, though; you might choose to postpone the migration, and offer a separate tool for the user to run.
This prevents any packages from depending on such a package, though: they can no longer be automatically installed, because their dependency cannot, too.
This changes the concept of package management seriously enough.
* If the package owns the file, and the user is not supposed to make changes to it, then package updates may do whatever to the file on update. It's good practice though, to leave a copy of the old file in /lost+found.
* If the user is allowed to make modification, then the user owns it. The configuration syntax becomes and API and should be treated as such. Breaking changes should be rare, preceded by a deprecation period and announced as major versions. As you say, it's questionable if such updates can/should be automated.
But, unfortunately, some software does not, and it still needs to be packaged.
Any admin can view the contents to debug or spot any potential security issues.
That’s because you probably never built a package management system. If you limit the package management system to the actions you propose it’s only usable for iOS type apps and that could be useful but then you still need a solution for managing the rest of the system.
In Nix postInstall (and preInstall, as well as preBuild/postBuild, etc) specifying commands to execute before/after the corresponding "phase" -- so if a package is "almost" good to go with just "make install", you could use postInstall to do something like copy a file omitted by upstream's installation target.
The point is that postInstall in Nix is part of how the package itself is constructed-- in contrast to commands run after installing the package. There is no equivalent for this in Nix in a fundamental way (not by policy or for technical reasons).
It's generally a good practice to make your system open for extension but closed to modifications [1].
There is no reason, the user database can not work the same way. Just have the system scan `/etc/passwd.d/*` on boot/reload and drop files there.
[1] https://drive.google.com/file/d/0BwhCYaYDn8EgODUxZTJhOWEtMTZ...
Schema migrations would still need a script or something though.
Mutable, persistent state is usually put under /var and is user-owned. Package updates should not touch data in there.
IMHO, a package should deliver a set of files to certain directories. That's it.
It should not overwrite existing files, that were installed by other packages. It should not change existing files in any way.
It might advise the system to trigger certain reindexing actions (systemd daemon reolad, update man-db, etc.) but doing this should be the duty of the package manager, not the package itself.
AFAIK, nix and Solaris' pkg are pretty close to this ideal.
A big advantage that this has, on top of security, is that:
- packages can be uninstalled safely and without side-effects
- package contents can be inspected (pkg contents)
- corrupted installations can be detected using checksums (pkg fix)
- package updates/installs can be rolled back using file system snapshots.