Re: pkgsrc and robotpkg

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

On Saturday, at 23:16, David Brownlee wrote:
| I think a more general solution to handling partial pksgrc checkouts
| would be interesting, but I'll defer that for now. It is interesting
| to see that you're having the same issue with robotpkg...

I was actually thinking of something simple, more or less like the way
"wip" is setup right now. Perhaps allowing one more hierarchy level, e.g.

pkgsrc/mk/*
pkgsrc/base/pkgtools/pkg_install <- here the mandatory pkgs
pkgsrc/base/...

pkgsrc/system/category/pkg <- all current pkgsrc packages would go here
pkgsrc/system/...

pkgsrc/wip/category/pkg <- like current wip w/ an extra category dir
pkgsrc/wip/...

pkgsrc/otherrepo/category/pkg <- local/externalized repository
pkgsrc/otherrepo/...

This may not be as simple however, if you consider that  users of e.g. the
'system/*' pkgs would want to have no 'builtin' pkgs, while users of 'otherrepo'
would want to have most of the 'system/*' pkgs set as 'builtin'.


| Iff you were looking to share pkgsrc & robotpkg in the same repo you
| could try to put the robo directories under pkgsrc in robo-image,
| robo-modeling, or robo/image robo/modeling, but that makes users have
| to go into pkgsrc/robo as the main working directory. You almost want
| to be able to have the system check through multiple top level
| directories (make VPATH anyone?), so you can have
| robo/{mk,image,modeling} and optionally robo/pkgsrc/{audio,...}

Yes, this more or less corresponds to my suggestion above :)
For the "working dir" problem, perhaps a general "pkgsrc" wrapper script could
wrap the "cd category/pkg && make target" commands, so that you can do from the
command line e.g.:
# pkgsrc update x11/gtk2


| So for those packages where you have set this in robopkg is there any
| reason they could not be merged back into pkgsrc? I'm wondering if
| there is any potential to keeping part of the pkgsrc & robopk trees in
| sync, so both can benefit from package updates in the other system.

Actually robotpkg and pkgsrc don't have any packages in common (or just a very
few). The goal is just to bridge the gap between general purpose software and
those software that are not packaged anywhere (for whatever reason:
insufficient quality, too little audience, not enough maturity...). Those
packages may reach the general public some day, and then they will be packaged
'normally', in pkgsrc and in other pkg systems as well.

So what I forked from pkgsrc is the mk/* infrastructure, not the package
descriptions! To handle dependencies correctly, those 'standard'
packages are described with a sole and simple Makefile fragment (very close to
'builtin.mk') that are called 'depend.mk' in robotpkg.
To be more concrete, you can have a look at those files there:
http://trac.laas.fr/git/robotpkg/tree/mk/sysdep
(that's GNU-make syntax btw...)

| As I understand robopkg will extract before building depends but would
| still build the depends before the configure step?

Right. There are two kinds of 'barrier' in robotpkg. The 1st one requires
'bootstrap-depends' only, while the 2nd kind requires the full 'depends'
target.

When two targets require different barriers, only the more demanding kind is
invoked, so 'make extract' requires only 'bootstrap-depends' but 'make
configure' will require both 'depends' and 'bootstrap-depends' via the 2nd kind
of barrier.

| I'd definitely be interested in seeing if more of the infrastructure
| could be kept in sync, with behavioural differences handled by mk.conf
| settings, but thats just me :)

Ideally yes, but a few things cannot simply be handled by mk.conf settings.
For instance, something that may seem awkard but that I have actually been
asked many times is the possibility to install a package from the HEAD of a
repository.

In robotpkg, for each pkg package, you can either install pkg-1.0, pkg-1.1
etc., or invoke "make checkout" and have your work/ directory populated with a
checkout of the pkg repository (defined via MASTER_REPOSITORY). If you install
that, you get a package with 'checkout-YYMMDD-HHMMSS' appended to its version
(similar to what PKGREVISION does). This is definitely handy for quickly
testing a patch in situation, but I'm really not sure this is a generally
useful (or even desirable) feature...