What’s New in EasyPBI 2.0
Greetings! With EasyPBI 2.0 now available in the FreeBSD ports tree and as a PBI in the AppCafe, I was asked to highlight some of the new features in EasyPBI 2.0, and why you should want to start using it now.
The first new feature that comes to mind is relatively minor, but saves a fair amount of time if you use EasyPBI with any regularity. This is the ability to check when the last time you updated your system ports tree was, and to use portsnap (or svn if appropriate) to update it to the current version. This is easily available from the “System → Get FreeBSD Ports” menu option.
The second new feature is more of a significant overhaul rather than a brand new feature, and that is making the module editor a complete front-end to editing PBI modules. Previously, the editor allowed the user to view and change the most common options for PBI’s, and trying to use smart defaults for the rest. Now, while still recommending smart defaults, it makes all the settings and options for the module available to the user. The is extremely useful for loading modules from other people, as you can now see everything that the module has inside it, with nothing being “hidden” from EasyPBI inside any of the configuration files. This is easily shown with the new “Scripts” tab in the module editor that lets you read through or edit any custom installation scripts that might be in the module. Another example of this is the new functionality in the “XDG Entries” tab that lets you view/edit any of the desktop/menu entries without having to guess what is inside based upon the file name as with the previous versions. Oh, EasyPBI is also able to set up MIME type file associations for menu entries now, making that whole process very simple and no longer requiring that the user know how to write XML files for the different MIME types.
The last new feature that I want to highlight is one that will not be used very often, but has some very powerful possibilities associated with it. This feature is the ability to package non-port programs in the PBI format. What this option does is basically shift the burden of compiling the program and all its dependencies onto the user instead of using the FreeBSD ports framework. To make this work, the user will first have to setup a directory on his system in the exact format that he wants it to have inside the PBI (with lib/ bin/ share/ etc/ sub-directories as appropriate), as if the program got installed into this directory instead of on the base system. Once that is ready, you can then point EasyPBI at that directory, give it a version number and other program information, then have it all be packaged up as a PBI. This will require a bit more “advanced” usage since you will have to setup external-links and desktop/menu entries for the application yourself (since EasyPBI relies on the FreeBSD ports framework for recommendations), but this ability has a lot of very powerful implications. For instance, it should now allow program developers who wish to distribute special closed-source versions of their software to still make use of the PBI format for simple installations and consistent runtime dependencies by their clients. While this next example was not what the PBI format was originally designed for, I could also see this also being used by device manufacturers to release additional closed-source drivers or FreeBSD kernel modules for their devices. This would provide a simple way to distribute and install these drivers without requiring the system users to have extensive knowledge of the FreeBSD system structure or go through the pain of compiling and loading kernel modules on their own.
These are just some of the new features of EasyPBI 2.0 that I think users will appreciate the most. If you have some “killer” feature that you would like to see in the upcoming versions of EasyPBI, please let me know! I can be found on the PC-BSD PBI developers mailing list, or you can send me an email directly.
 ken (at) pcbsd (dot) org
Trackback from your site.