[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: suggestion: Host fly-off between pkgin and nih and subsequent official integration
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
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
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
Unfortunately I could not find enough time for this. But this task is
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?
Main Index |
Thread Index |