Re: suggestion: Host fly-off between pkgin and nih and subsequent official integration

[Aleksey Cheusov <cheusov%tut.by@localhost>]

 >> Previuos functionality provided by FreeBSD ports? ;-) Definitely!

> yep.  However, I think the technology gap betweens ports and pkgsrc is
> closing

Every time I meet or listen to FreeBSD users I find that pkgsrc is
significantly better than their ports. And yes, pkgng is a huge step
forward for them.

>, and current is smaller than most pkgsrc dev's think.  For me,
> the most obvious deficiency is the lack of a mandatory DESTDIR

Personally, I think that in a long run support for USE_DESTDIR=no should
be removed.  AFAIK there are only a few dozens of packages that don't
support DESTDIR.  If you have some spare time and energy feel free to
fix them ;-)

 >> Is it time to try out pkgin or nih? ;-)

> yes, but that was sort of the point of this thread.  If one of these
> was just "forced" on everyone rather than optionally installed, pkgsrc
> would be at its best.  Obviously SmartOS is doing exactly this.

pkgsrc users have a choice. This is good. I still don't see any reason
to force users to use either pkgin or nih.

 >> Package building should be done only in chroots or VMs if we have root
 >> priviledges.
 >> FreeBSD oldtimers may disagree with me.

> This is really the crux of the issue.  1) the chroot and pbulk
> building is incredibly cumbersome to set up and the documentation
> seems to be outdated on top and

Ask Joerg to update documentation and simplify configuring or try distbb.
Maybe you'll find it easier :-) Seriously, in nearest future I'll
implement support for automatic "buildbox" (chroot) creation in distbb
as pkg_comp did many years ago. And I hope, distbb will become much
easier to use. So, this is known and well understood problem.

> 2) people used to FreeBSD are expecting to be able to build from
> source.  Until recently it never even occurred to me that I would be
> expected to rebuild every dependency of every new package I want to
> add on the fly.  However, that's really the only way to reliably do it
> (coupled by pkgin/nih)

I don't understand your task here.

 >> This is not a problem of pkgsrc. This is a problem of those who use
 >> wrong tools for package building ;-)

> Which perfectly illustrates my point that pkgsrc doesn't consider this
> a problem, but classifies it as user error.

This is not a problem of users. This is a problem of choice.  If someone
wants to use pkg_rr or 'make replace' and feels comfortable with them, I
cannot stop them. Nobody can. This is their choice. I'm pretty sure I
can build and install everything I need with a help of distbb+nih
without problems you mentioned. So, your examples seem to me irrelevant.

pkgsrc provides low level functionality for building and updating
packages. Unless you are expert in pkgsrc, I'd recommend not to use it
directly. That is, forget about "make install", "make replace" and so
on. Don't blame low level tools, use higher level ones instead: distbb,
pkgin, pbulk, nih etc.

> I think it's great that multiple people think they
> have the best solution but at some point shouldn't there be a
> technical "fly-off" and one solution anointed as the official tool?

> Or is the intent that nih and pkgin can both be installed and used
> interchangeably since they are both wrappers?

If pkgin correctly handles "automatic" flag in pkgdb (pkg_add -A), then
yes, pkgin can easily be replaced with nih and vice versa at any moment
in time.  As I said in the past in nih I use features provided by pkg_*
and pkgdb and nothing else.

pkg_install + pkgdb provide very good API, nih/pkgin/whatever -- use it.
This is how I see the package management in pkgsrc.

-- 
Best regards, Aleksey Cheusov.