For many of these, using puppet templates will be a viable alternative. There may be cases where a change is needed during installation, and we'd have a couple of options there. In some cases, we may be able to package an override file. Alternatively, we could use the kickstarts to make changes during postinstall, if absolutely necessary. We'd need to look at them case by case to decide what the best option would be. -----Original Message----- From: Saul Wold [mailto:sgw@linux.intel.com] Sent: Wednesday, August 08, 2018 9:35 PM To: Rowsell, Brent; starlingx-discuss@lists.starlingx.io Subject: [Starlingx-discuss] Creating new packages for Initialization / Configuration files Brent, et al: There are a number of packages that contain modified configuration files that bring in alternate default files and in some cases modified initialization scripts. Currently there are puppet packages that do some configuration management. We could continue with puppet for these configurations that we want to disengage from the upstream patches, or we can use RPM package. Thoughts? Examples of configuration patches from stx-integ/base are: centos-release (issue files) iptables (iptables rules) dhcp vim (vimrc!) lighttp pam sanlock shadow sudo util-linux Regarding centos-release Issue files: As you saw today, I proposed removing the issue* files from a otherwise unmodified centos-release package, is there a reason that we need to restore those issue files for an Open Source OS Independent project? Those modified issue files contain legalize that seems appropriate for a commercial product, but not sure if makes sense for an Open Source project that a downstream OSV or other company would likely modify for their use anyway. Sau! _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss