tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

pkgsrc and robotpkg


I had recently an e-mail conversion with Hubert Feyrer about the "robotpkg"
project (see
and ).

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


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 
| 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 
| 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 
| 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.

Home | Main Index | Thread Index | Old Index