Date: Tue, 30 Mar 2010 00:54:19 -0700 From: Garrett Cooper <yanefbsd@gmail.com> To: Matthias Andree <matthias.andree@gmx.de> Cc: FreeBSD Ports <ports@freebsd.org>, Florent Thoumie <flz@xbsd.org> Subject: Re: [RFC] deprecate @exec and @unexec in plists in favor of pre-install and post-install scripts Message-ID: <7d6fde3d1003300054x47c6ec2dj91a6473445d69f98@mail.gmail.com> In-Reply-To: <op.vabuhvhe1e62zd@balu.cs.uni-paderborn.de> References: <7d6fde3d1003272314r25305a39mce9893e07453ef90@mail.gmail.com> <op.vabkfdrt1e62zd@merlin.emma.line.org> <a01628141003290210w45432af9o57a8a045d0bb92cb@mail.gmail.com> <7d6fde3d1003290308m1cdde98dr1231b55ebad8f45c@mail.gmail.com> <op.vabuhvhe1e62zd@balu.cs.uni-paderborn.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Matthias,
Just to clear things up a bit, pkg_install (which lives under
.../src/usr.sbin/pkg_install) is a suite of tools consisting of
pkg_{add,create,delete,info,version}.
On Mon, Mar 29, 2010 at 3:35 AM, Matthias Andree <matthias.andree@gmx.de> w=
rote:
> 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.
>
> OK.
>
[...]
>> 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) doe=
s
> 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. =A0How do we create a package to
> pkg_install? =A0Currently 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).
>> =A0 =A0Exactly. pkg_create does properly document this functionality, bu=
t
>> 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
>> functionality.
>
> I have no objections, I just want to (a) understand the issue, and (b) ma=
ke
> 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 :).
>> =A0 =A0I 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 li=
ke
> 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):
http://wiki.freebsd.org/Revised_pkg_install
Cheers ;),
-Garrett
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7d6fde3d1003300054x47c6ec2dj91a6473445d69f98>