Re: pkgsrc and robotpkg

[David Brownlee <abs%netbsd.org@localhost>]

In an ideal world a single packaging system could handle everything
required by normal pkgsrc users and robotpkg without significant
compromises from either. That may not be possible, but its probably
worth determining what makes sense to share between the systems. A
fork is only a bad thing if the tines never gain from each other's
experience :)

On 19 November 2010 11:15, Anthony Mallet <anthony.mallet%laas.fr@localhost> 
wrote:

>
> On Thursday, at 14:51, Aleksej Saushev wrote:

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

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

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

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

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

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.

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

As I understand robopkg will extract before building depends but would
still build the depends before the configure step? This is a different
feature and may well be worth abstracting out into a mk.conf setting
for pkgsrc too :)

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

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 :)