pkgsrc and robotpkg

[Anthony Mallet <anthony.mallet%laas.fr@localhost>]

Hi,

I had recently an e-mail conversion with Hubert Feyrer about the "robotpkg"
project (see http://www.feyrer.de/NetBSD/bx/blosxom.cgi/nb_20101112_0805.html
and http://homepages.laas.fr/mallet/robotpkg ).

Hubert asked me the obvious question "why robotpkg was forked from
pkgsrc instead of committing new packages in pkgsrc/wip", and then advised me
to post my reply here, so that we can further discuss about this with
interested people. I can of course give more technical detail about any item
below.

Best,
Anthony


On Saturday, at 16:11, Anthony Mallet wrote:
| On Friday, at 08:05, Hubert Feyrer wrote:
| | One question: why did you decide to do your own spin-off from pkgsrc, 
| | instead of integrating the packages into pkgsrc or pkgsrc-wip?
| 
| Briefly, there are a number of different reasons, driven by the following
| statement: robotpkg is not meant to be a replacement for the system's package
| management tool (it does not superseeds pkgsrc, dpkg, macports etc.). The goal
| is to package software that is not widely available on a platform, and that's
| mostly "lab software" (generally of lesser quality than widely available
| software). robotpkg mostly targets PhD students working in robotics, so that
| they can easly setup their workstation and also easly make their software
| available for others. Thus, robotpkg is a little bit closer to a "development"
| tool than pkgsrc, because packages change (a lot) more often, and more
| drastically (I told you about the quality ;).
| 
| - Currently, pkgsrc mixes both infrastructure (mk/*) and packages
| themselves. For a student working on e.g. Linux, checking-out the whole pkgsrc
| tree (plus probably wip) would be cumbersome: it would be redundant with the
| base Linux pkg system, plus it would be difficult to isolate the specific
| robotic packages from the rest (the rest usually being available in the base
| system).
| 
| - We need a number of features not available in pkgsrc (and probably not 
really
| useful to pkgsrc either). The most important feature is to be able to detect
| "system packages", that are considered as "external software not in robotpkg
| but usually available on a unix system". This is done through a modified
| "buildlink" system, similar to the "builtin" packages of pkgsrc, but
| unified and generalized to all packages.
| 
| Other features include the possibility to generate a distfile from a
| specific tag in a cvs/git/svn repository or the option to bypass the 
"distfile"
| and work directly from a checkout of a repository. This later workflow is not
| encouraged, but it is convenient to quickly test a -current version of some
| software to see if it causes any problem. This is probably not something you
| would want in pkgsrc?
|
| Finally, there are a number of additions/changes corresponding to legitimate
| users requests and the specifc workflow in which robotpkg is used. They would
| have been more difficult (longer) to integrate in pkgsrc. You can for instance
| "make extract" without installing dependencies first (to look at the source
| code), you can define "sets" of packages to "make install/update/replace" on a
| set all at once (equivalent of pkg_chk+pkg_rolling_replace, but directly
| provided by the infrastructure). Makefile variables have also been 
"simplified"
| in some cases and most of the configuration of a package is done via the
| inclusion of the equivalent of "buildlink" files, so that any user can easily
| write a new package without remembering too much syntax.
| 
| Still, robotpkg directly uses some of the pkgsrc tools unchanged, like of
| course pkg_install, digest, tnftp, pax... The binary packages are
| thus directly compatible.