View Single Post
Posts: 3,401 | Thanked: 1,255 times | Joined on Nov 2005 @ London, UK
#115
Originally Posted by ARJWright View Post
Pardon the noob knowledge/understanding on packaging, but isn't the fact of whether the Qt APIs are packaged with DEB or RPM determined by the IDE used? And isn't all dev being funneled through Qt Creator? So why would the packaging be a problem - except for those that like to "package by hand" (which is what I'm guessing happens more often than not because the tool(s) aren't up to snuff)?
Another package format means more deployment testing. It increases the chance of an application c0cking up a device or the application failing to install. This means more work and puts more responsibility on the developer - easiest solution is not to support DEB.

DEB then becomes a legacy packaging format that everyone will want to forget as soon as possible. Developers that only have access to a new MeeGo device and with no access to an N900 won't create DEBs, just RPMs. N900 development declines.

Maemo5 can be 100% compatible with MeeGo at the Qt API level, but while it uses an incompatible package manager I think the number of MeeGo apps that are made available for Maemo5 will be much lower than might be otherwise be expected.

I'm not suggesting that DEB should be continued as I fully accept RPM is now the future, just that for the N900 to remain relevant it would be better if it could somehow acquire RPM support (how that happens I have no idea - the obvious solution would be to port RPM-based MeeGo to the N900, though there may be other options).
 

The Following 7 Users Say Thank You to Milhouse For This Useful Post: