Packager Workflow

From LSDevLinux
Jump to: navigation, search

There are three distinctly separate roles in the enterprise of writing software and getting it distributed to users:

  • the software developer
  • the packager
  • the repository manager.

Although it is possible that one person might from time to time wear all three hats, different skill sets really are required for each of these jobs and so it is desirable that these roles be considered as if they were fulfilled by different people. Ideally, software developers should not have to be involved in the packaging process at all so that they can concentrate on writing software. Likewise, packagers should not have to be experts about the inner workings of the repository system in order to package the software that has been written.

The basic work-flow for a packager is intended to be as similar as possible to the way that things are done in the main Debian and/or Ubuntu worlds. The main reason for not trying to reinvent the wheel yet again is that extensive documentation, tutorials, etc. have been written for developing packages for Debian/Ubuntu and it only makes sense to capitalize on that work. As far as interacting with the repository is concerned, things should be kept simple as possible for the packagers and be as similar as possible to the process of packagers interacting with the Debian and Ubuntu projects.

In the Debian/Ubuntu worlds, there are basically two different models used by packagers:

  • the isolated developer (one package == one developer)
  • the collaborative team (pool of packages maintained by a pool of developers)

These two paradigms could lead to slightly different work-flows that could be implemented.

In the case of the isolated packager, the packager would prepare the package using established methods and upload the properly signed source package to the appropriate incoming directory. At that point, automated tests would be run on the package and the package would be built. If everything was successful, then the package would move to the appropriate place. If any errors occurred during the testing or building, the package would be rejected and an email sent to the packager so that they could address the issues of what went wrong. Since some testing is done automatically, this should actually decrease the amount of effort that the packagers have to do currently in properly maintaining a package.

With the team approach, the packagers could work together and use some sort of source control system while developing the packages. In this scenario, a packager would send a signed command to the repo server. This message would then check out a copy of the package and then retrieve the source tar ball of the packaged application from the appropriate place before proceeding to check and build the package as above. The exploration of this option would be contingent on enough of the packagers choosing to collaboratively work this way. In practice, this is only an additional front-end to the repository system but it does have the potential for reducing the bandwidth requirements of the developer.

We could go either way, or even both, with this depending on the actual desires of the packagers. A better description about these two models and the rationale behind them can be found at