tech-pkg archive

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

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?

Home | Main Index | Thread Index | Old Index