Clone wiki

vpackager / About

Project History

The vpackager project started within vectorlinux as a tool to help people convert a source code archive into an installable vectorlinux package that could be easily (un)installed. The first version was an interactive bash script which simply asked a few questions, and started building the code.

Later versions implemented a GUI written in gambas2. The gambas version featured all the characteristics of the old bash version, but with more enhancements, and a front end to cruxports4slack. By this time, vpackager was a tool capable of generating packages that met the requirements for submission to the vectorlinux repositories. However, changes to the prerequisites for built packages rendered vpackager back into a tool for end-user only, meaning, packages generated by vpackager could not be submitted to the repositories.

The furute of the project

The purpose of the project has always been 2 major points.

  • Help end-users package and install software straight from source requiring a minimal ammount of knowledge or experience from the user.
  • Make a packager's job easier by proving a way to create package using a point and click method rather than manually building packages.

The project will continue to be developed around this concept and purpose, targetting both the end-user and the more experienced packager who contributes to the development of the distro.

New in development

Further development for this project is being done in python rather than gambas2. Python offers more flexibility and modularity, which is a must for the way this application is developed. Future versions will include a GTK+ front end, and possible a urwid front end (not completely sure).

Changes in the backend

The application will obviously be a combination of front and backend. The backend consists of python modules that actually build the code in a threaded process. A dispatcher system is implemented to schedule tasks.

Rather than being an on-demand type of application, vpackager will be further extended to work more like a build bot. With this idea, vpackager will depend on sqlite where a database will be kept. The database basically consists of 2 tables as describe below.

  • queue (job queue)
    • id
    • source URI
    • description URI
    • etc
  • history (build history)
    • id
    • source URI
    • time stamp when build started
    • path to stdout
    • time stamp when build ended
    • build result
    • etc

The GTK front end will be used to manage the task list, view history, and manage overall build settings.