tech-pkg archive

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

Re: Seeking review of wip/freem package

On 8/19/21 5:15 AM, Greg Troxel wrote:

"John P. Willis" <> writes:

I'm hoping to get some community review/feedback on my "freem" package
in pkgsrc-wip, so I can get an idea of what the next steps are/what changes
I need to make for inclusion in mainstream pkgsrc, in addition to wanting
the package to be of good quality.

Looking very quickly (and some of this is for the benefit of others as a
sort of checklist)

   pkglint reports no issues

   If you haven't built with "PKG_DEVELOPER=yes", please do.  (Really, if
   you are developing packages, just set that in general for your

I have built with PKG_DEVELOPER=yes since beginning this project.

   TODO is empty (besides 'ask for review'), which is good.

   I tend not to have a double lank line before bl3 section.  Not a big
   deal, maybe that's just me.

   Typically is last, after the included bl3 files.

Will fix.

   DESCR typically does not point to docs.  HOMEPAGE is there for finding
   the canonical entry page.  This package installs docs (which is great)
   and presumably if a pointer is warranted it would be in there.  So I
   would just drop that line.

Will also fix.

   There is no MESSAGE, which is good.

   There are no patches which is a nice sign about upstream, and I would
   have checked that patches are explained and filed upstream with
   bugtracker URLs unless they are clearly not appropriate for upstream.

   It looks like man pages (or sources?) are also installed in
   share/doc/freem.  (They are installed in man directories, which is
   good.)  I don't follow this, and it seems from Makefile like an
   upstream bug or difference of opinion on norms.

I'll look into this and see if I can figure out what's going on.
I am both the package developer and the upstream developer.

   I wonder if the sysconfdir argument is needed as I would expect
   GNU_CONFIGURE to arrange for that automatically.  But I'm fuzzy on
   that, so this may just be my confusion.

It seemed I needed to do that due to a difference between the
pkgsrc expectations and Autotools defaults.

   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).

   The previous comment might not apply to journals.txt.  But usually for
   var-ish things the package would create the directory and not the
   file, which would be created at runtime.

   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.

and not about the package but

   upstream gets nerd style points for an info file (seriously, not


Home | Main Index | Thread Index | Old Index