Date: Mon, 29 Mar 2010 13:35:45 +0300 From: "Matthias Andree" <matthias.andree@gmx.de> To: "Florent Thoumie" <flz@xbsd.org>, "Garrett Cooper" <yanefbsd@gmail.com> Cc: FreeBSD Ports <ports@freebsd.org> Subject: Re: [RFC] deprecate @exec and @unexec in plists in favor of pre-install and post-install scripts Message-ID: <op.vabuhvhe1e62zd@balu.cs.uni-paderborn.de> In-Reply-To: <7d6fde3d1003290308m1cdde98dr1231b55ebad8f45c@mail.gmail.com> References: <7d6fde3d1003272314r25305a39mce9893e07453ef90@mail.gmail.com> <op.vabkfdrt1e62zd@merlin.emma.line.org> <a01628141003290210w45432af9o57a8a045d0bb92cb@mail.gmail.com> <7d6fde3d1003290308m1cdde98dr1231b55ebad8f45c@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Garrett Cooper wrote on 2010-03-29:
>>> WRT variables, I'm not so concerned about %D %F etc, but I am concerned
>>> about the necessity to add script boilerplate (such as snatching
>>> pre-post or
>>> deinstall-install modes, prefix), and while I haven't thoroughly
>>> audited the
>>> install scripts in ports, I see lots of bad shell scripts around. These
>>> would need rigorous audits (in adverse conditions, such as paths
>>> containing
>>> blanks and shell meta characters to unveil underquoted
>>> parameters/variables).
>
> 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.
>>> Also, this effort alone isn't any help in reducing code duplication,
>>> as in
>>> my perception the duplication is between Makefile (for port install)
>>> and
>>> pkg-plist/pkg-install (for packages). There often is some line similar
>>> to
>>>
>>> ${SETENV} PKG_PREFIX="${PREFIX}" ${SH} ${PKGINSTALL} ${PKGNAME}
>>> POST-INSTALL
>>>
>>> in the ports' Makefiles (post-install or whereever appropriate).
>
> 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.
> 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?
> 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
> functionality.
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.
> 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 :))
--
Matthias Andree
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?op.vabuhvhe1e62zd>