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

[John Marino <netbsd%marino.st@localhost>]

On 4/16/2013 17:25, Aleksey Cheusov wrote:
> Previuos functionality provided by FreeBSD ports? ;-) Definitely!

yep.  However, I think the technology gap betweens ports and pkgsrc is 
closing, and current is smaller than most pkgsrc dev's think.  For me, 
the most obvious deficiency is the lack of a mandatory DESTDIR (which 
I've grown to love about pkgsrc), but this is also in the works for 
ports, but will be known as "staging" since FreeBSD (rather 
unfortunately) uses the term DESTDIR for something else.  The other 
clear deficiency is the use of ldconfig instead of embedding rpath but 
maybe staging will help convert those.

> In case pkgsrc/nih you'll introduce circles because it has dependencies.
> pkgin is selfcontained.

Yeah, pkg intentionally bundled software that is available in ports in 
order to remove all dependencies.  It obviously has to be buildable as 
the first package, or the scheme doesn't work.

> The same for pkgin and nih. I'm very well aware of apt functionality.
> I cannot say too much about pkgin, but nih provides some functionality
> absent in apt/yum/zypper/pkg/pkgin.

agreed.  they are all comparable to apt.

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


> revdumps is completely different problem.

I wouldn't say it's unrelated.  When revbump signal an incompatible API 
changed, they are necessary.  When they are used to force rebuilds in 
pbulk, that's pro-builder, anti-user.  That's a clear policy decision by 
pkgsrc.

>     And then it fails because the package is already installed.
> I'm not sure I understand you here. pkg_add -U?

pkg_add doesn't help because everything is being built from source. 
That's the scenario I'm defining.  When you "make" a package, sees a 
revbump and is compelled to rebuild a package that is already installed 
on the system even though the package that is installed is perfectly 
adequate for the package you are trying to build.  So it rebuilds it and 
fails at the install phase because the package is already installed.  (I 
don't know of any env. variable that will case pkgsrc to automatically 
"replace" packages instead of stopping in the case).

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


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


> I planed  to combine nih and distbb to solve this problem a couple of
> years ago.
> Unfortunately I could not find enough time for this. But this task is
> feasible.


I think that's fine but the discussion basically started with the 
observation that there are multiple "options" available to users, but no 
official ones.  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?