Experimental Physics and
Industrial Control System

"Konrad, Martin" <[email protected]> · Wed, 14 Feb 2018 21:55:41 +0000

Hi Lewis,
> it's the upstream developer of a piece of software who is responsible
> for ensuring it works correctly on any supported platforms (i.e.,
> platforms the developer is willing to support).
Unfortunately, developers often don't have enough time to perform
thorough testing on multiple platforms. It can also be hard for a
developer to foresee all the strange characteristics of all the
different systems out there. And putting them all into the source code
of the upstream project does not necessarily make things better. Instead
I think developers should focus on writing good, portable software.

Here are some of the things I consider the job of the package maintainer:

- ensure everything builds fine against the libraries that come with the OS
- ensure that all files end up in the right spot
- ensure that services can be started smoothly (think of init scripts
vs. upstart vs. systemd)
- ensure a good user experience by following the conventions used in the
ecosystem (Debian maintainers often patch upstream software to use a
more secure default configuration)
- defining dependencies between packages
- ensure upgrades can be performed smoothly

Software developers can make this process easier by following best
practices (like adhering to the File-system Hierarchy Standard rather
than dropping files into arbitrary directories that might exist on their
favorite system only).

> Certainly I wouldn't do it for no reason, but you're limiting 
> yourself by choosing a packaging system that supports Debian-based 
> platforms only.  With pkgsrc, you could focus on Debian-based 
> platforms only, but at least the packaging system would not 
> effectively rule out support for other platforms.
I'm surprised nobody brought up containers, yet. They also solve the
problem of bundling up applications in an OS-independent way and they
have gained quite some popularity. However, keep in mind that they also
have some downsides:

- upgrading popular libraries (e.g. libssl or libCom) might require
rebuilding and redeploying _a lot_ of containers. Rebuilding and
redeploying a shared library with a traditional package might be much
easier/faster
- it might be harder to tell which software (and which version) is
installed on which machine (in the context of security vulnerabilities
this might be an important question)

See [1] for more reasons why having a maintainer in between the
developer and the user might not be a waste.

>> 2) Real maintainability. It occurred to me very quickly that 
>> packaging is not a one-time project - the fact which is sometimes 
>> overlooked. Keeping it properly viable, updated, and tested is a 
>> dedicated effort; reacting quickly to upstream changes and user 
>> requests defines how useful the packaging is to users.
I agree. I guess our next big job is making sure our packages build fine
on Debian 9.

> As far as the cost of multi-distribution and multi-platform packaging
> goes, that would be one of the main reasons for an open source
> packaging effort: by working on a system that can be extended to meet
> the needs of others on different platforms, you increase your chances
> of getting more contributions from others.
Yes, but at the same time this increases complexity significantly. From
my perspective it's probably not worth it.

Also keep in mind that the list of operating systems that are popular in
the EPICS community on PC-like hardware is surprisingly short:

- Debian (very stable, huge amount of packaged software available, great
development tools and community)
- Ubuntu (derived from Debian, requires only very minor modifications to
the existing Debian packages)
- RedHat (can buy support, even for real-time systems)

Also: In my experience packaging a new application can be anywhere
between "a breeze" (developer followed best practices) and "almost
impossible" (crappy code, developer came up with tons of esotheric
solutions). A significant part of the packaging effort has to do with
fixing issues upstream and educating upstream developers. Once a project
has been packaged, packaging for other operating systems is usually much
easier.

> Security updates are not released for more than two quarters back, I
> think, but in a trusted environment, you could ignore that.
Our Debian machines only install signed packages. Easy to do and
eliminates one attack vector. Let's not use the fact that Channel Access
doesn't offer security (yet) as an excuse for not applying best
practices to other things.

Regards,

Martin

[1] http://kmkeen.com/maintainers-matter/2016-06-15-11-51-16-472.html

-- 
Martin Konrad
High Performance Controls Team Leader
Facility for Rare Isotope Beams
Michigan State University
640 South Shaw Lane
East Lansing, MI 48824-1321, USA
Tel. 517-908-7253
Email: [email protected]

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System