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>