I totally disagree
Ok. There are so many hidden assumptions here in the article that
it seems too much to rebbutle. Let me start:
0. We DONT want the packaging system to be interactive (.deb is a very BAD example of that). We want the SOFTWARE installed to be interactive and provide a configuration utility. When the package itself is interactive the original package programmer has less to do and you wind up with a package that needs to be reinstalled to reconfigure. This is very bad from a software development stand as it produces very low quality software and package systems should not forgive software that cannot be reconfigured by doing it for them. Besides, if Im installing netscape and it depends on a new secure protocol packages you mean that I have to answer questions like - "Number of bits in key generation algorithm ring = 56 ? (correct ?) "... All this for installing netscape ?
1. Another reason package interactive configuration is bad is that in the future there will many more packages with a lot of dependencies and installing one may cause installation of a 100 packages - do we realy want to answer all of their questions about configuration ? let them install with default configuration and provide reconfig utilities.
2. DONT put any semi aritificial intelligence features in package management system (not at the core anyway...). We all know that those features are not realy intelligent. Take for example the RPM feature of keeping the old configuration files. It is a total bullshit feature. What if the new version also has a new format for the configuration file ? I'll wind up with an application that doesnt work. Flexibility for the programmer behind the application should be maintained. What the package management system should give the programmer behind the application is the ability to run a special tool which will be in the package to do an upgrade and THATS it!!!!. This way I could move from standard .rc file format to XML .rc and not worry about my users (I'll just add a script to the package that converts the old format to XML and that script will be run by the package management tool when it detects that theres an upgrade going on...). In any case, upgrade is a messy business, so dont let package management systems fool you into thinking that they handle it "automatically..".
3. All in all, "smart" features should not enter the package management tools core system (we all know that that is wrong in any software system...). I'd much prefer a simple package management tool with a strong database behind it and a simple policy about upgrades - it installs the new packages and tells you about configuration files that you messed with and puts copies of them on the side for you to re-apply your changes. At least then I'll know that upgrade is complicated rather than be lied to and find that when I cant run the application, or worse, when the application runs in a mysterious buggy way...
4. Another thing which this article does not address is uninstall. The biggest thing about uninstall is that you want it to GUARANTEE that the uninstall returns the system to the same state before the install. This means that pre and post scripts are BAD. Yes. Im suggesting dumping them all together. They are a big security hole (dont talk about package source authentication - what if the programmer of the script had a bug and removed my kernel ? what if I dont know the company giving me the package and the package is a trojan into my system ? stop thinking about geeks who will scan the scripts with their eyes and think about my mother double clicking the package... besides - by definition I'm a qualified geek and I've installed hundreds of rpms and havent scaned any of them - who has the time ?). The idea is that pre and post stages will still be maintained but the packager will only have a limited selection of actions that could be performed at these stages and each of them will be reversible (and will actually be reversed) by the uninstall process. All in all Its a good idea to push software writers to the edge where they think that they have to do all of their configuration with a tool that they provide (they hate that but that is the future...).
Way to go
This is the best thing I have heard from Troll Tech yet.
I am very glad at this and have a few comments:
1. Troll Tech will not regret this - this descision will bring more developers to work with Qt and ultimately more money to Troll Tech for consulting and enhancements.
2. The gathering of a lot of companies in one stand againt the Redmond monster is a blessed thing. This descision will bring less division between the Gtk and Qt communities and will let organisations like Debian distribute KDE.
Thank you Troll Tech. I'm on my way to learn some Qt.