Page 1 of 2 12 LastLast
Results 1 to 20 of 24
  1.    #1  
    This is a request for comments (RFC) on an idea I've been rolling around in my head since webOS 1.4 was released. The culmination of the idea may allow us to merge the Package Manager Service into Preware, ending up with a single package that can be installed with palm-install, and can safely be removed using orange+tap. The technique should also allow us to do the same for any other advanced homebrew package. Read on for more details ...

    Palm has added some interesting new functionality in webOS 1.4 related to package management.

    Our homebrew packaging standards and the Package Manager Service functionality has always been founded on the principle that homebrew installation should mirror as closely as possible the operation of the palm-install script in the webOS SDK. If we always stick close to that, then we know that we'll be compatible with what Palm expects to happen when a developer installs a test version of their webOS application using the SDK before submitting it to the official Palm App Catalog.

    Prior to webOS 1.4, the major difference between what palm-install script does and what the Package Manager Service and WebOS Quick Install have had to do to support advanced homebrew packages (like Services, Plugins, Themes, Patches, Optware, etc) is the execution of post-install and pre-remove installation scripts. These are the scripts which hook Services and Plugins into the underlying operating system (and unhook them on removal), which install and remove Themes (without the safety measures of AUPT), and which incorporate AUPT to safely install and remove Patches.

    Now in webOS 1.4, Palm has added support to the ApplicationInstallerUtility for running installation scripts. For some reason they chose not to use the standard locations for the scripts in the ipkg format (Preware has always used the standard locations, and do many other embedded systems that use the standard ipkg tool and formats), but have defined two new locations in Palm's version of the ipkg format for pmPostInstall.script and pmPreRemove.script files. These files are executed when palm-install installs a package (using the installNoVerify method of com.palm.applicationManager), and when orange+tap removes a package, and end up being stored in the new /media/cryptofs/apps/.scripts directory.

    My conjecture is that they have done this so that they can distribute advanced applications in the app catalog that install services or plugins - for example, Flash support comes to mind as something that would need this. We have also found working /var/palm/event.d and /var/palm/system-services areas which mirror the corresponding areas under /etc, but allow services and upstart jobs to be installed without needing to modify the read-only root filesystem (i.e. installed in a way such that a partial erase can remove them easily), and an lnsa-tool script which seems to tie all this new functionality together.

    I've been testing this new functionality over the last couple of days, and believe that there is a way to create advanced homebrew packages that can use these new Palm install script locations in addition to the existing ipkg standard installation script locations, allowing for a seamless transition from one generation of advanced homebrew packaging standards to the next.

    The other consequence of all this is that we can employ a C programming language version of org.webosinternals.ipkgservice which uses this new package management functionality available in webOS 1.4, with the following benefits:

    1) Closer compatibility with palm-install and orange+tap
    2) Integration of ipkgservice into a single Preware package
    3) Clean removal of all traces of ipkgservice on Partial Erase
    4) No longer needs to restart Java when installing Preware

    There is however, one major drawback - it would mean that this new version of Preware would only work on webOS 1.4 or later.

    So, I'm looking for input on this proposal from the advanced homebrew developers who create these services, plugins, themes and patches (e.g. Eric G, Brandon, Ryan, Eric D, Rick, Jason R, Will, Marcus, Brian, Daniel, Thomas, Klaus, Farhan, Zeb, Tobias, Jason S, ...) and any other interested parties.

    -- Rod
    Last edited by rwhitby; 03/07/2010 at 04:29 AM.
    WebOS Internals and Preware Founder and Developer
    You may wish to donate by Paypal to donations @ webos-internals.org if you find our work useful.
    All donations go back into development.
    www.webos-internals.org twitter.com/webosinternals facebook.com/webosinternals
  2. acydlord's Avatar
    Posts
    67 Posts
    Global Posts
    72 Global Posts
    #2  
    If everything works the way it is laid out here I think it would be a great idea but I think it should not be implemented until all carriers are pushed the 1.4 update unless the current methods/version are left along side so no one is left in the dark until their carriers get 1.4
  3. #3  
    As an interim step, would it be possible to have 2 parallel versions of Preware available, old and new, perhaps with an install check on new to ensure that the user has the right OS version? {Jonathan}
  4. #4  
    Quote Originally Posted by rwhitby View Post
    So, I'm looking for input on this proposal from the advanced homebrew developers who create these services, plugins, themes and patches.
    As a Debian Developer I really miss the possibility to use postinst/prerm. I just package normal apps but even here I need it for example to create directory structures in /media/internal or repair broken stuff from previous installs when the package is installed. Currently I'm doing this in the startup script of the app but this means the user has to start the app once to get the necessary directory structure which is quite annoying.

    I vote for switching to the scripts which are used by Palm because:

    1. Using standard postinst/prerm which is only used by Preware/QuickInstall is useless for me because I always install test versions of my apps with palm-install because it's the easiest way for me to install a package.

    2. I never delete apps with Preware, I always do it by orange-clicking. So in my opinion compatibility to this deletion method is important.

    3. If I upload my package to the official app catalog then I want the scripts to work, too. So I have to use the Palm scripts anyway.

    4. I don't think that the 1.4 requirement is an important disadvantage. People who use Preware or WebOS Quick Install are some sort of hackers anyway and these sort of people always install the latest firmware as soon as possible.

    But if there are still countries which have no 1.4 yet then the release of this new Preware should be delayed until then, I think.
  5. #5  
    I think the advantages outweigh the disadvantages! Very soon every carrier (if not already?) should be on 1.4, and I don't see a real reason not to update. So in the long term, the new method seems to be much cleaner and more compliant with the Palm way.
    IPK FETCHER <-> An attempt against geo-filtering
  6.    #6  
    Quote Originally Posted by kayahr View Post
    3. If I upload my package to the official app catalog then I want the scripts to work, too. So I have to use the Palm scripts anyway.
    You should clearly understand that unless you are in a large business relationship with Palm (like Motion Apps, or EA Games), you will go through the normal app submission process, which has an automated stripping of such scripts for obvious security reasons.

    So anything that uses these scripts will only ever be able to be installed with palm-install, WebOS Quick Install or Preware. Never from the app catalog.

    -- Rod
    WebOS Internals and Preware Founder and Developer
    You may wish to donate by Paypal to donations @ webos-internals.org if you find our work useful.
    All donations go back into development.
    www.webos-internals.org twitter.com/webosinternals facebook.com/webosinternals
  7.    #7  
    Quote Originally Posted by acydlord View Post
    If everything works the way it is laid out here I think it would be a great idea but I think it should not be implemented until all carriers are pushed the 1.4 update unless the current methods/version are left along side so no one is left in the dark until their carriers get 1.4
    All devices on all carriers have 1.4.0 available.

    Webos Doctor Versions - WebOS Internals

    -- Rod
    WebOS Internals and Preware Founder and Developer
    You may wish to donate by Paypal to donations @ webos-internals.org if you find our work useful.
    All donations go back into development.
    www.webos-internals.org twitter.com/webosinternals facebook.com/webosinternals
  8. 2xs
    2xs is offline
    2xs's Avatar
    Posts
    29 Posts
    Global Posts
    30 Global Posts
    #8  
    PRO merging! :thumbsup
    current devices: PRE+
  9. #9  
    I think this is the way to go

    However one Question, what happens to Apps which require Package Manager service to function, such as Luna Manager?
  10. #10  
    Quote Originally Posted by rwhitby View Post
    You should clearly understand that unless you are in a large business relationship with Palm (like Motion Apps, or EA Games), you will go through the normal app submission process, which has an automated stripping of such scripts for obvious security reasons.
    Does this mean they are restricting the "game" app type, too? Because with this type I can start shell scripts which have the power to do everything on the system. So I see no point in allowing the game app type but no postinst scripts.

    But anyway: Even when this advantage no longer exists, there are still enough advantages left. So I still think it is a good idea to switch to the palm scripts.
    My apps: ScummVM | Destroids | Minimap
    My phone: Palm Pre 2, webOS 2.2.4, OČ Germany
  11. #11  
    Quote Originally Posted by Shadow-360 View Post
    I think this is the way to go

    However one Question, what happens to Apps which require Package Manager service to function, such as Luna Manager?
    Good question.

    In any case, I support the move, granted we:

    • Educate users on the simple differences between say a "Preware Classic" and the new Preware (not that there should be much need for the old with 1.4 spreading)
    • Somehow, become relatively certain that palm intends to keep this new setup (at least for the foreseeable future). Last thing we need is Preware going haywire on a new OS release because they changed file paths like in 1.3.5 - I've learned from themes that having to rehaul your code everytime palm updates can be a pain (since they thankfully keep the OS updates coming pretty frequently)


    Great detective work by the WI team as usual
    PreThemer - Palm Pre Themes, Wallpapers & Bootlogos - packaged for easy installation. Themers! Post your themes!
    ***UNINSTALL THEMES BEFORE INSTALLING NEW ONES!***

    My Themes | Follow @PreThemer on Twitter!
  12. #12  
    Well, I'll have to think about this one some more before I can pick a side. On the one hand, rolling everything into one package would make homebrew just a hair more approachable for newbs, and would simplify updates.

    On the other hand, the old UNIX/Linux philosophy keeps coming to mind: "Do one thing, and do it well." As any developer knows, any time you add features to a project/package, the complexity increases, as does the chance of weird bugs that are hard to track down. Combining two packages that do different things is even more complex.

    The other reason for that philosophy is to minimize bloat/cruft. One of the things that turned me off OOo was the fact that (on my system anyway) the core package accounted for the majority of the weight. So, for instance, if you only wanted OOo Calc you still had to install a huge core package, and what you ended up with was not much smaller than a complete install. Obviously Preware and PMS don't take much space, but my point is to me it's all about choice.

    That said, either way wouldn't break my heart.
    Treo 300 > Hitachi G1000 > PPC-6700 > PPC-6800 (Mogul) > PPC-6850 (Touch Pro) > Palm Pre & HTC EVO Optimus V
  13.    #13  
    Quote Originally Posted by kayahr View Post
    Does this mean they are restricting the "game" app type, too? Because with this type I can start shell scripts which have the power to do everything on the system. So I see no point in allowing the game app type but no postinst scripts.
    Yes, type:game is also rejected at the moment.

    My conjecture is that they'll need to put some sort of sand-boxing or non-privileged user arrangement for security in for type:game before they accept them through the general public app submission process. Unless they plan to review the source code of every type:game submission. There's no way they can allow unreviewed root execution scripts in the app catalog - for one thing, if they ever did then we would be able to distribute Preware via that mechanism.

    -- Rod
    Last edited by rwhitby; 03/07/2010 at 03:08 PM.
    WebOS Internals and Preware Founder and Developer
    You may wish to donate by Paypal to donations @ webos-internals.org if you find our work useful.
    All donations go back into development.
    www.webos-internals.org twitter.com/webosinternals facebook.com/webosinternals
  14.    #14  
    Quote Originally Posted by Shadow-360 View Post
    I think this is the way to go

    However one Question, what happens to Apps which require Package Manager service to function, such as Luna Manager?
    The org.webosinternals.ipkgservice Mojo service will still remain. It will just be installed as part of Preware instead of as part of a separate package.

    Note that the Luna Manager application may well be going away at some point, since it has been incorporated into Preware anyway.

    -- Rod
    WebOS Internals and Preware Founder and Developer
    You may wish to donate by Paypal to donations @ webos-internals.org if you find our work useful.
    All donations go back into development.
    www.webos-internals.org twitter.com/webosinternals facebook.com/webosinternals
  15. #15  
    Last I checked, everyone is now has the ability to be at 1.4.
    As long as a pre-1.4 version is available for those that Doctored back for various reasons, we should be good.

    webOS Developer
  16. #16  
    I believe this would probably be a good move - however I would strongly suggest that on the backchannel you speak with Palm to ensure that, given you'll be using their method, they won't change it and/or otherwise mess anything up.
  17. #17  
    Just wanted to pop in here and voice my stance on the option:

    I'm all for it!

    Palm removed any app security they had when they added type:game functionality and the ability to use plugins from any location.

    Removing postinst/prerm security in Preware/WOSQI to switch to Palm's script system is no more harmful. And hey, it has the added advantage of orange-tap cleanly removing it.

    As it seems that most everyone agrees in favor of the new postinst/prerm system, I'll schedule adding that format of install to WOSQI v3.1. And I'll include backwards comparability for the current postinst/prerm format, of course.
    If you've liked my software, please consider to towards future development.

    Developer of many apps such as: WebOS Quick Install, WebOS Theme Builder, Ipk Packager, Unified Diff Creator, Internalz Pro, ComicShelf HD, LED Torch, over 70 patches and more.

    @JayCanuck @CanuckCoding Facebook
  18. #18  
    I can't find anything of importance to say that hasn't already been said. So:

    Great idea! Native C PMS should = faster!
    dBsooner
    WebOS-Internals Member and Developer
    Donations Appreciated!

    Keep up to date with webOS-Patches via Twitter: @dBsooner

    Browse Patches @ WebOS-Patches Web Portal - (Trac)
    Submit New Patches @ WebOS-Patches Web Portal
    Submit Updated Patches @ WebOS-Patches Web Portal
  19. #19  
    Quote Originally Posted by rwhitby View Post
    The org.webosinternals.ipkgservice Mojo service will still remain. It will just be installed as part of Preware instead of as part of a separate package.

    Note that the Luna Manager application may well be going away at some point, since it has been incorporated into Preware anyway.

    -- Rod
    If you get rid of the Luna Manager application, We would have to login to Preware (up to 2 mins depending on feeds) to do a Luna restart?

    Not sure I like that but the New-PreWare version sounds good. I mean we would no longer have to install 2 things for more advanced homebrew applications right?
    Please hit the thanks button if I helped you

    If you've enjoyed my patches please feel free to donate towards further development.

    Follow the link below.


  20.    #20  
    Quote Originally Posted by 2sslow View Post
    If you get rid of the Luna Manager application, We would have to login to Preware (up to 2 mins depending on feeds) to do a Luna restart?
    For the times when you want to do a luna restart *outside* of Preware, you could use Jason's patch to the Launcher menu to add those options.

    Not sure I like that but the New-PreWare version sounds good. I mean we would no longer have to install 2 things for more advanced homebrew applications right?
    Correct.

    -- Rod
    WebOS Internals and Preware Founder and Developer
    You may wish to donate by Paypal to donations @ webos-internals.org if you find our work useful.
    All donations go back into development.
    www.webos-internals.org twitter.com/webosinternals facebook.com/webosinternals
Page 1 of 2 12 LastLast

Posting Permissions