Re: pkgsrc and robotpkg

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

Hi Aleksej,

Just to clarify a few points before answering to your questions: the goal of my
e-mail was not to blame pkgsrc anyhow nor say that pkgsrc is missing this or
that. I am myself a pkgsrc user on Linux and NetBSD and I am quite happy with
it. I wouldn't have based robotpkg on pkgsrc otherwise :)

The fact is that robotpkg started as an attempt to teach our students the
notion of "package", "release", "installation" etc. in the software they
develop. This was 4 years ago now, and I was not actually sure at that time if
the approach was right (for instance compared to making dpkg, rpm or whatever
packages).

I started initially from a very much stripped down version of pkgsrc, because
the goal was not to have the universal tool, but rather something handy and
simple to understand (for the students, again). I wanted to be reactive to
users requests and feeback and provide them exactly the tool they wanted, which
has lead to the current (slight) differences from pkgsrc. It's not that I am
especially happy with the fork, but I felt that this was -at least initially-
necessary to boostrap the process in the students mind :)


On Thursday, at 14:51, Aleksej Saushev wrote:
| 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.

What you suggest is exactly what I call cumbersome. robotpkg targets users that
are not computer scientists, and that are not ready to do what you suggests.
But I agree that technically, it would be possible to hide this behind some
"bootstrap" script for instance.
And it's not for saving space, but for clarity (normal users use e.g. yum to
install their regular sofware of e.g. fedora).

Still, I think it would be interesting to have the "infrastructure" separated,
and a set of possibly different packages repository. That said, robotpkg
currently suffers from the very same problem.


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

For clarity, I find it better to have real category names, like "net", "math",
"image", "modeling" etc. Categories that are meaningful for robotics and for
the students.


| How does it differ from builtin?

This is the big point. The robotpkg mechanism differs from builtin in that the
"builtin" feature is systematic, for all packages. Any package can be
configured (by end users) to be either "system" (external) or "robotpkg"
(internally managed). For "system" packages, robotpkg checks the presence of a
few representative files of the packages (like some headers, .pc files etc.),
then report about the installed version found, the installation prefix etc. so
that the configure step of a package can be told where its dependencies are
living thanks to variables like PREFIX.pkg, CPPFLAGS.pkg etc. And some of the
packages that will never be packaged in robotpkg have only a "system" version
in mk/sysdep/xxx.mk (no Makefile, PLIST etc.).

| make extract SKIP_DEPENDS=yes
| make help topic=SKIP_DEPENDS

Thanks! I was actually not aware of this (this used to be NO_DEPENDS iirc).

But again, while I am myself very happy with typing "SKIP_DEPENDS=yes", this is
not true for the users of robotpkg. They actually expect this to be the default
behaviour, and this actually makes sense I think. But that's definitely a 
detail.


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


I am not sure this leads to time waste as the set of packages are totally
different (no redundancy). Furthermore, the robotpkg Makefiles are really close
to those of pkgsrc. And you could as well talk about the time waste between
rpm, dpkg, macports, freebsd ports etc... , no? :)

| Perhaps it were much easier to create one additional module in pkgsrc-wip 
project.

Yes, but at the price of forgetting about the "system" (builtin) vs. "robotpkg"
packages described above (plus all the other little differences).