[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 Tue, Apr 16, 2013 at 5:06 PM, John Marino <netbsd%marino.st@localhost> wrote:
> On 4/16/2013 20:58, Aleksey Cheusov wrote:
>>> 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.
> I honestly had not heard of distbb before today. I have been thinking that
> pkgsrc doesn't know what it's missing by not having poudriere (and it
> doesn't) but it seems like distbb is a similar idea. These tool have to be
> much easier to use otherwise it will stay in the realm of the developer and
> not the regular user.
>> 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.
> I suspect you probably misunderstood me. Pkgsrc makes one jump through
> absurd hoops when building from source over a long period of time where the
> branch gets updated. This is not a problem for FreeBSD ports, yet users are
> told that these updating issues are caused by users "misusing" pkgsrc.
> Nobody "wants" to use rolling replace, they are forced to. Nobody "wants" to
> use "make replace", they are forced to.
>> 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.
> pkgin and nih: useless if there are no available binary packages prebuilt
> distbb: I infer it's not a level for the non-developer yet
> pbulk: I *know* it's not a level of the non-developer yet
> So you're basically saying: DragonFly users should be given a set of
> prebuilt binaries for quarterlies, and not build from source because pkgsrc
> itself is too low level for the basic user. This issue is that this is a
> essentially correct assessment.
I'm not sure where you're getting these sweeping opinions of pkgsrc
usage being "correct", etc, but I do agree that there isn't a good way
to upgrade when you build from source.
I often forget how many dependencies there are for something and wind
up typing in a password ~1M times to upgrade some little thing. A
failure half-way through is a real mess.
I think there hasn't been a focus on this use case because the focus
has been on the ability to do unprivileged builds, DESTDIR support,
etc. (builders vs users)
I don't think it's the opinion of every pkgsrc developer that there
shouldn't be an easier way to safely upgrade a package because you
happened to need some non-default options or a newer version or run a
platform without binary packages.
I absolutely think a good solution should exist, be easy to use, and
even be included by default.
On the flip side, I also think NetBSD (and DFBSD, and ~everything)
should be working hard to provide binary packages, variants of binary
packages with options enabled, etc
Main Index |
Thread Index |