My work towards getting P2-RPM integration is leaning towards an end. Patches are in gerrit, here and here. While Eclipse with the patches is being built, I have plenty of time to think.
I've been with P2 since it was announced at EclipseCon 2008 in Santa Clara. It's hard to remember how crowded was the room, but I remember my sheer enthusiasm to the idea of solving the satisfiability problem, and runnig the optimal set of bundles.
Little had I know how much influence it will have on me. But P2, and especially dropins, were supposed to be my daily bread for the next couple of years.
Then I changed the job, hoping for something new, but P2 did not let me to forget. Fedora turned out to rely on dropins (because there was *no* alternative). I tried to change Fedora, but was confronted with 20+ years of Linux releng, and got really convinced that P2 could have been quite different.
So, how the P2 could have look like now?
The core P2 functionality, responsible for installing things, should *not* be running in JVM. Java itself is not granted on every computer, and it has plenty of dependencies (at least on Linux), which makes it very unwanted member of the installer stack. Not to mention that it adds size to the installer, which is really important in the case of corporate setups and people using modems. Another problem is that P2 running in JVM cannot update that JVM because of locking. Not to mention the lack of elevated privileges support.
I can easily imagine P2 being a native, embeddable processing library that would rather work take the state of a system, the request, and respond with steps leading to another state, but without really touching anything, but just letting the installer to deal with file operations.
I'd be the first to work on it to integrate it fully into RPM and make it responsible for the whole Linux installation - not just Eclipse.
Disclaimer: Don't be afraid. Those are only my thougths, which (un)luckily I'm not able to materialize without making many people upset.
No comments:
Post a Comment