tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Seeking review of wip/freem package



"John P. Willis" <jpw%coherent-logic.com@localhost> writes:

>>    PLIST has things in var/freem.  I don't follow this at all because the
>>    files don't appear (I have read zero of your docs!) to be things that
>>    are modified.  If they are sort of library files to be read then they
>>    belong in share/freem if they are independent of CPU type and probably
>>    lib/freem of libdata/freem if they depend on cpu type.
>>
>
> The M programming language has a database integrated. FreeM organizes
> related databases and routines into "namespaces", which by default are
> USER and SYSTEM. USER routines and databases go in
> $PREFIX/var/freem/USER/{routines,globals} and can be modified by any
> user on the system.
>
> The SYSTEM namespace holds library code and databases that are
> accessible to all users, but with the requirement that SYSTEM
> databases
> are read/write to everyone, but SYSTEM routines are read-only to
> everyone but the system manager/superuser.
>
> I'm of course open to suggestions as to where to put the namespaces,
> and can probably defer creation of some of those locations to runtime
> within the "fmadm" (FreeM Administrator) utility. (Specifically "fmadm
> configure", which must be run prior to using FreeM at all).

Given your description of how they are used, the paths do not troubling.

There is a notion that var-type stuff from packges goes in VARBASE,
rather than $prefix/var.   I just checked a few systems and on netbsd
this defaults to /var.

>>    var raises the question of uid, because a var dir needs a uid and
>>    often packages that are daemons run under a specific uid that is
>>    created as part of the package.  But programming languages aren't like
>>    that.  So a var-like place needs to be in some cache or config dir in
>>    a per-user sort of place.  I simply have not dug in to what's going
>>    on, but hope this is helpful.
>
> The "fmadm" utility will set permissions appropriately when
> creating/managing routines, databases, and namespaces.

ok, but I think for pkgsrc the choice is

  get permission right at creation time

or

  defer creation to fmadm

Attachment: signature.asc
Description: PGP signature



Home | Main Index | Thread Index | Old Index