[RFC] deprecate @exec and @unexec in plists in favor of pre-install and post-install scripts

2010-03-27 Thread Garrett Cooper
Hi, As part of taking a look at the differences in our implementation of pkg_install(1) in order to afford an improvement over the existing code, I've looked at various implementations of pkg_install, one being NetBSD's evolution [1]. It's several years ahead from our's and while I don't believ

Re: [RFC] deprecate @exec and @unexec in plists in favor of pre-install and post-install scripts

2010-03-28 Thread Garrett Cooper
On Sat, Mar 27, 2010 at 11:14 PM, Garrett Cooper wrote: > Hi, >    As part of taking a look at the differences in our implementation > of pkg_install(1) in order to afford an improvement over the existing > code, I've looked at various implementations of pkg_install, one being > NetBSD's evolution

Re: [RFC] deprecate @exec and @unexec in plists in favor of pre-install and post-install scripts

2010-03-29 Thread Matthias Andree
Am 28.03.2010, 08:14 Uhr, schrieb Garrett Cooper: Hi, As part of taking a look at the differences in our implementation of pkg_install(1) in order to afford an improvement over the existing code, I've looked at various implementations of pkg_install, one being NetBSD's evolution [1]. It's se

Re: [RFC] deprecate @exec and @unexec in plists in favor of pre-install and post-install scripts

2010-03-29 Thread Florent Thoumie
On Mon, Mar 29, 2010 at 7:58 AM, Matthias Andree wrote: > Am 28.03.2010, 08:14 Uhr, schrieb Garrett Cooper: > >> Hi, >>    As part of taking a look at the differences in our implementation >> of pkg_install(1) in order to afford an improvement over the existing >> code, I've looked at various impl

Re: [RFC] deprecate @exec and @unexec in plists in favor of pre-install and post-install scripts

2010-03-29 Thread Garrett Cooper
On Mon, Mar 29, 2010 at 2:10 AM, Florent Thoumie wrote: > On Mon, Mar 29, 2010 at 7:58 AM, Matthias Andree > wrote: >> Am 28.03.2010, 08:14 Uhr, schrieb Garrett Cooper: >> >>> Hi, >>>    As part of taking a look at the differences in our implementation >>> of pkg_install(1) in order to afford an

Re: [RFC] deprecate @exec and @unexec in plists in favor of pre-install and post-install scripts

2010-03-29 Thread Matthias Andree
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

Re: [RFC] deprecate @exec and @unexec in plists in favor of pre-install and post-install scripts

2010-03-30 Thread Garrett Cooper
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 wrote: > Garrett Cooper wrote on 2010-03-29: > [...] >> It's real

Re: [RFC] deprecate @exec and @unexec in plists in favor of pre-install and post-install scripts

2010-03-31 Thread Alexander Leidinger
Quoting Florent Thoumie (from Mon, 29 Mar 2010 09:10:54 +): I mentioned getting rid of those pesky @*exec lines a few years ago, but this was met by quite a lot of objection. I still think it would be a good change, assuming that we provide equivalent (or better) features: - Configuration

Re: [RFC] deprecate @exec and @unexec in plists in favor of pre-install and post-install scripts

2010-03-31 Thread Florent Thoumie
On Wed, Mar 31, 2010 at 11:49 AM, Alexander Leidinger wrote: > Quoting Florent Thoumie (from Mon, 29 Mar 2010 09:10:54 > +): > >> I mentioned getting rid of those pesky @*exec lines a few years ago, >> but this was met by quite a lot of objection. >> >> I still think it would be a good change

Re: [RFC] deprecate @exec and @unexec in plists in favor of pre-install and post-install scripts

2010-03-31 Thread Alexander Leidinger
Quoting Florent Thoumie (from Wed, 31 Mar 2010 12:00:53 +): It could serve as a proof of concept and would show more clearly what you have in mind. Done nicely, it also allows to keep a lot of the stuff in the Makefile and only write such scripts by hand if absolutely necessary (think about