Anthony Mallet <anthony.mallet%laas.fr@localhost> writes: > 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. > > 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). How is that cumbersome? If you're severely space constrained, you can check out "mk" and several packages in pkgtools, devel, net, archivers, and sysutils subdirectories. You usually just don't need it. You can put your packages in separate subdirectory. E.g. I have several additional subtrees in my /usr/pkgsrc: "local", "local-cfd" and some more. > | - 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. How does it differ from builtin? > | 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? Yes, it presents problems for pkgsrc, but we use it in wip. Even if I haven't committed the code to skip caching stage, I have it, you could just ask questions or explain what you need or want. > | 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), make extract SKIP_DEPENDS=yes make help topic=SKIP_DEPENDS > | 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. I'm not sure this justifies the fork, but I'm sure that this leads to time waste, instead of working on common set of packages, we work on two different ones without knowing about it. At least you could announce the fork, so that we knew about it. Perhaps it were much easier to create one additional module in pkgsrc-wip project. -- HE CE3OH...
Attachment:
pgp9hXVDVbYEy.pgp
Description: PGP signature