Experimental Physics and
Industrial Control System

Hello everyone,

thanks for your valuable comments and discussion on the matter. Many important considerations were highlighted in this thread, and we were thinking of and discussing various ways to address legacy and upgrade concerns and suggestions given current needs and resources available.

In short, the existing repository structure which we have is used internally and referenced externally and cannot be easily decommissioned. At the same time, we would like to have something more current to bring latest packaging efforts from epicsdeb. Combining both efforts in a single solution is challenging, let alone upgrading the approach for more powerful cases of multi-distribution building or continuous pipeline to bring latest upstream in the packaging.

The initial plan was to move all legacy packages in the new repository structure which then would be populated with new contents for Debian 8 and 9. This idea was squashed by original sources inconsistency between old and new setups which denied the possibility of pulling old packages in the new repository easily. Moreover, it would be difficult to establish a clear naming for repository snapshots old and new.

As it is seen now, the existing repository structure will be retained under  http://epics.nsls2.bnl.gov/debian/. In addition to that, the plan is to add a new, separate public mirror which would include recent available packages from epicsdeb, e.g. under http://epicsdeb.nsls2.bnl.gov/debian/. Eventually and as the system upgrade commences, the old repository will (hopefully) cease to be used and will be decommissioned. The new repository structure will support staging, main, and potentially snapshot repositories for Debian 8 and 9.

Compared to some suggestions raised in this thread, such as supporting multi-distribution and multi-platform packaging, changing the packaging method (e.g. pkgsrc) and build infrastructure, etc., this "solution" (or more like expansion of practice) is relatively cheap. Unfortunately and as mentioned by some others, pursuing effective solutions requires significant dedication and effort with design requirements spanning way past the delivery solution itself (e.g. testing, delivery, flexibility, maintenance etc.).

As always, we welcome any comments on the matter!

Thanks,

Anton.