Subject: Re: Overhauling PLIST command set
To: Johnny Lam <firstname.lastname@example.org>
From: Alistair Crooks <email@example.com>
Date: 11/07/2005 22:25:36
On Sun, Nov 06, 2005 at 03:46:37PM -0500, Johnny Lam wrote:
> Stoned Elipot wrote:
> >On Fri, Oct 28, 2005 at 04:32:5e1PM +0200, Thomas Klausner wrote:
> >>Long term, I'd like to move the following features which are currently
> >>implemented using shell scripts into the pkgtools, too. Not right now,
> >>though, getting rid of the @exec's comes first.
> >>. info file
> >>. user/group
> >>. /etc/shells
> >>. config files
> >>. reference count dirs/files
> >>. font handling
> >>. permissions
> >And what the rationale for this long term goal ?
> Just to provide some belated input, I think this long-term goal is good.
> Currently, the code that handles the above-mentioned items is in the
> +INSTALL script for each package. The problem with this is that the
> code is actually part of the package -- if there are bugs that need to
> be fixed or improvements that we wish to make in the code, then the
> changes can only apply to future packages that we create, and existing
> binary packages and even pre-installed packages on the system are stuck
> with the old code. Moving the code into the install tools themselves
> fixes this problem.
This is probably an artefact of adding things on as the system has
grown, and it probably came to us before pkgsrc existed, from FreeBSD.
I think the goal is correct, but my reasons are different to Johnny's.
Mainly, I'd like to have a "packing list" that is exactly that - a
list of files and directories. No extra @exec or @unexec statements,
which belong in the +INSTALL scripts. This is for no other reason
that aesthetics. Aesthetics, and a need for the tools to lose some
bloat in the pkg_add front, to get rid of the possibility of running
something horrible unknowingly as root at installation or
de-installation time, a separation of the +INSTALL work to the script
and not the pkg_install tools. And the roads, the water supply, etc.
> The question of how to do this while preserving the flexibility we
> currently have by using +INSTALL scripts is a separate issue -- for
> example, I think it would be wrong to put the code into pkg_add and
> pkg_delete, but rather there should be a separate pkg_* tool that
> performs these actions.
This begs a number of questions, but let's not go there right now. If
we want to add flexibility, but not bloat the tools, there are other
options, such as to make a user-management package, a shell-management