[RFC] deprecate @exec and @unexec in plists in favor of
pre-install and post-install scripts
yanefbsd at gmail.com
Tue Mar 30 07:54:21 UTC 2010
Just to clear things up a bit, pkg_install (which lives under
.../src/usr.sbin/pkg_install) is a suite of tools consisting of
On Mon, Mar 29, 2010 at 3:35 AM, Matthias Andree <matthias.andree at gmx.de> wrote:
> Garrett Cooper wrote on 2010-03-29:
>> It's really no better passing in these values in +CONTENTS [// *plist]
>> form because a lot of this stuff is fed through to vsystem eventually
>> [a pkg_install home-grown variadic version of system(3)], which means
>> that all bets are off then, minus the initial @cwd stuff (but that's
>> fine because it's handled from within pkg_install anyhow.
>> This doesn't make sense to be honest... *sigh*. There's already a
>> well-established format in pkg_install that should be leveraged
>> instead of reinventing the wheel for ports...
> Well, basically what the line above (in a port's post-install target) does
> is to run the installed PKGINSTALL script to do its job.
> I've only never understood why a port maintainer has to this explicitly,
> when Mk/bsd.port.mk could as well handle it.
> It appears to me that we are in violent agreement on this one.
Yes, except with placement. The reason why I veraciously and
vehemently vote for it being done in the pkg_install infrastructure is
that anything sitting in ports is isolated to ports, and as such the
logic either needs to be `statically correct' (meaning that if I
install my package version of the port anywhere it needs to do the
right thing as far as picking up where it should be installed, how it
should act, etc -- maybe with some minor adjusting as per rtld, etc to
ensure that it behaves as expected at runtime -- which is already
fudged in via bsd.ports.mk).
>> No need; pkg_add and pkg_delete already do this and do it fairly well,
>> and pkg_install should be called from ports anyhow because it is the
>> package maintenance tool...
> I'm not sure I understand your proposal. How do we create a package to
> pkg_install? Currently that's "make install", "make package" (ok, the
> latter implies the former), which adds a few +... files (+CONTENTS and
> thereabouts) and then runs pkg_create, right?
Correct. From a little lower level, make package feeds data via stdin
(mostly pkg-plist) to pkg_create -f - , which then goes, registers the
install in /var/db/pkg (or $PKG_DBDIR if defined elsewhere), then
completes the dirty deed. Looking at bsd.port.mk reveals a good deal
in this regard (look for PKG_CMD -- not sure why that's the
nomenclature for the variable).
>> Exactly. pkg_create does properly document this functionality, but
>> unfortunately it's really underused in the ports infrastructure and
>> instead all of this stuff is jammed into the +CONTENTS [/*plist]. This
>> is what should be avoided because we've just made the plists into a
>> veritable 7-11 for all of the pkgs needs instead of using duplicated
> I have no objections, I just want to (a) understand the issue, and (b) make
> sure we have proper and strong (not to say compelling) arguments in favor of
> your proposal, and (c) avoid that new crutches would have to be invented.
Understood. If my aim doesn't improve things then: a) it should be
revised, or b) it should be scrapped.
Perhaps I need to setup a prototype to show what I mean? Shouldn't
take more than a weekend and it would prove more fruitful than me
spinning my wheels monkeying around with python plists :).
>> I was also hoping to converge into a more sensical model like
>> NetBSD has created over the past 4 years -- and this is one of the
>> gaps that I think we should cross in trying to make this possible. The
>> overall goal is to make a logically sound change that would reduce
>> maintenance for everyone in the ports community.
> That's the second time the reference to NetBSD has appeared, would you like
> to add any pointers to highlights of the NetBSD system?
> (It's been a while since I've used pkgsrc if that's what you're implying,
> and only on Linux :))
Yes, but like FreeBSD, NetBSD has its packaging roots in jkh's
pkg_install. They've just been running off in a different direction
since 2006; it's not necessarily the tangent that I personally think
we should follow completely to a tee because there's additional
complexity introduced ala yaml, etc, but that's up to portmgr and
arch@ to decide what and how we should progress when we get to that
point; several interested folks (bapt, etc) -- including myself help
make sure we do it along with other interested folks. Here's the
updated wiki page for the work (it's a draft, but as with most wiki
pages, that's to be expected :P):
More information about the freebsd-ports