Experimental Physics and
Industrial Control System

"J. Lewis Muir" <[email protected]> · Tue, 13 Feb 2018 17:36:02 -0600

On 02/13, Michael Davidsaver wrote:
> Lewis,
> 
> On 02/13/2018 08:33 AM, J. Lewis Muir wrote:
> > On 02/12, Anton Derbenev wrote:
> >> Any thoughts on the matter are also welcome.
> > 
> > Hello, Anton!
> > 
> > I think your project is a good, but I think even better would have
> > been to use pkgsrc <https://www.pkgsrc.org/>
> 
> Have you tried working with this tool?

Hi, Michael!

Yes, I have.

> I hope you'll forgive me a rant,

Of course! :-)

> but I've been doing packaging on various platforms for 15
> years now.  Ever since a search for "make uninstall" led me to
> http://checkinstall.izto.org/
> 
> I wish this problem was as simple as tooling...
> 
> See for reference the Debian Policy Manual
> (https://www.debian.org/doc/debian-policy/) and Lintian
> (https://lintian.debian.org/).  Yes, there is a linting tool for
> debian packaging.
>
> The redhat equivalent to this is I think
> https://fedoraproject.org/wiki/Packaging:Guidelines although it's been
> a while (9 years) since I've written a .spec file.

I've never written a Debian package, and I think the last time I wrote a
.spec file was six years ago.

I've never read the Debian Policy Manual, and I read some kind
of RPM packaging guide (maybe the same one you referenced)
when I last wrote that .spec file.  pkgsrc has a guide at
<http://www.netbsd.org/docs/pkgsrc/>.

I haven't used the Debian package linter to know how it compares, but
pkgsrc has one too: pkglint (pkgtools/pkglint).

> > instead of Debian packaging.
> > It's probably too late for you to change, and I don't want to sound
> > critical but with Debian packaging, you are only reaching sites and
> > users who use a Debian-based distribution.  (I'm sure there are tools
> > to convert .deb into whatever, but I doubt many in the EPICS community
> > are using them, and I don't know how seamless the experience would be.)
> 
> Not nearly as seamless as native/complaint packaging, sometimes to the
> point of being unusable.  eg. look for upgrades to silently leave behind
> missing libraries due to incomplete dependency lists.

Good to know; that's what I was afraid of.

> Following a distribution policy gives a level of "just works" which isn't
> attainable with the various meta packaging tools like pkgsrc, the
> translators like alian, nor the shell scripts which grow, like mushrooms,
> around any binaries stored on an NFS share.

:-)

I would not lump pkgsrc together with translators nor shell scripts.
pkgsrc has a guide and standards for where things should be located,
etc.  You have to specify a prefix for where pkgsrc packages are
installed (e.g., /opt/pkg), and packages can be cleanly managed under
that tree.  (FYI, there's no such thing as a relocatable pkgsrc binary
package; the prefix and file paths are baked into the binary package.)

It's not easy to do all of this right, but it is possible.  It won't be
native in that it won't install under /usr/bin, for example.  It won't
be native in that it will not adopt the file system layout of Debian,
for example.  Still, it will be sane and consistent under its tree, and
it can be pretty close to "just works."

There's a binary package manager for pkgsrc called pkgin
<http://pkgin.net/>.  Assuming you are providing an EPICS package
repository for pkgsrc, you'd build all the packages and host them
somewhere, and then you would provide a user with a pkgsrc bootstrap kit
that would include pkgin, and then the user would use pkgin to manage
the packages like apt/yum.

One possible limitation is that I'm not sure anyone mixes binary
packages from multiple pkgsrc repositories.  This is not necessarily the
end of the world, but it is a concern.  I've looked into this because
I've wanted to use the binary packages from a public repository and
only build from source the binary packages for my internal packages,
but I think it was suggested that I'd run into problems.  But it may
be because of pkgsrc options that can be set for packages, and if my
options are different from the ones used to build the binary packages in
the public repository, things will break.  If my options are exactly the
same, though, then I'm wondering if it would be fine.

FYI, Joyent uses pkgsrc to provide binary packages for SmartOS/illumos,
macOS, and Linux.  See <https://pkgsrc.joyent.com/>.

> > You're probably not reaching any site or user who uses CentOS, RHEL,
> > or any other non-Debian-based Linux distribution.
> 
> With the (qualified) exception of ITER.  To my knowledge, none of the
> sites using the redhat based distros are using RPMs to distribute epics
> modules.
> 
> The best response I've had is "If you do the work, we'll look at it".
> Which is no kind of motivation given the time needed to enable such a
> "look".

Yes, I agree, that's kind of disappointing.

> Of course, if you'd like to change this then I'm all ears.

I would like to change this, but I don't have the time right now that is
necessary to contribute in a meaningful way.  If the package management
system was pkgsrc, I probably would have contributed and probably would
be contributing now because I would have probably wanted to use that
system to install EPICS Base and friends on most of the machines under
my control (most of which are not Debian-based).  But maybe in the
future?

Regards,

Lewis

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System