<  committed a1aa043

  • Participants
  • Parent commits 6626dfa

Comments (0)

Files changed (1)

+== 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 mysql where a database will be kept. The database basically consists of 2 tables as describe below.
+ * todo (todo list)
+    ** id
+    ** source URI
+    ** description URI
+ * history (build history)
+  ** id
+  ** source URI
+  ** time stamp when build started
+  ** path to stdout
+  ** time stamp when build ended
+  ** build result
+The GTK front end will be used to manage the task list, view history, and manage overall build settings.