Re: [HELP NEEDED] LUA expert to help convert fedora-release %post scripts
On 03/03/2016 02:39 PM, Florian Weimer wrote: > On 03/03/2016 04:00 PM, Stephen Gallagher wrote: >> I'm attaching the current fedora-release.spec and convert-to-edition bash >> script >> for perusal. > > I'm attaching a lightly tested Lua conversion. I'm not familiar with > all the scenarios to test, so I thought I'd post what I have quite > early. Most of the pieces should be in place. > > Florian > Thanks, Florian. I cleaned up a few very minor issues and submitted pull requests for both Rawhide and F24: https://pagure.io/fedora-release/pull-request/29 https://pagure.io/fedora-release/pull-request/30 Thank you very much. I really appreciate you taking the time to help with this and also your incredibly fast turnaround on it. signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: [HELP NEEDED] LUA expert to help convert fedora-release %post scripts
On 03/03/2016 04:00 PM, Stephen Gallagher wrote:
> I'm attaching the current fedora-release.spec and convert-to-edition bash
> script
> for perusal.
I'm attaching a lightly tested Lua conversion. I'm not familiar with
all the scenarios to test, so I thought I'd post what I have quite
early. Most of the pieces should be in place.
Florian
%define release_name Twenty Four
%define dist_version 24
%define bug_version 24
Summary:Fedora release files
Name: fedora-release
Version:24
Release:0.12
License:MIT
Group: System Environment/Base
URL:http://fedoraproject.org
Source: %{name}-%{version}.tar.bz2
Source1:convert-to-edition.lua
Obsoletes: redhat-release
Provides: redhat-release
Provides: system-release
Provides: system-release(%{version})
# Kill off the fedora-release-nonproduct package
Provides: fedora-release-nonproduct = %{version}
Obsoletes: fedora-release-nonproduct <= 23-0.3
Provides: fedora-release-standard = 22-0.8
Obsoletes: fedora-release-standard < 22-0.8
Requires: fedora-repos(%{version})
BuildArch: noarch
%description
Fedora release files such as various /etc/ files that define the release.
%package cloud
Summary:Base package for Fedora Cloud-specific default configurations
Provides: system-release-cloud
Provides: system-release-cloud(%{version})
Provides: system-release-product
Requires: fedora-release = %{version}-%{release}
%description cloud
Provides a base package for Fedora Cloud-specific configuration files to
depend on.
%package server
Summary:Base package for Fedora Server-specific default configurations
Provides: system-release-server
Provides: system-release-server(%{version})
Provides: system-release-product
Requires: fedora-release = %{version}-%{release}
Requires: systemd
Requires: cockpit
Requires: rolekit
Requires(post): sed
Requires(post): systemd
%description server
Provides a base package for Fedora Server-specific configuration files to
depend on.
%package workstation
Summary:Base package for Fedora Workstation-specific default configurations
Provides: system-release-workstation
Provides: system-release-workstation(%{version})
Provides: system-release-product
Requires: fedora-release = %{version}-%{release}
# needed for captive portal support
Requires: NetworkManager-config-connectivity-fedora
Requires(post): /usr/bin/glib-compile-schemas
Requires(postun): /usr/bin/glib-compile-schemas
%description workstation
Provides a base package for Fedora Workstation-specific configuration files to
depend on.
%prep
%setup -q
sed -i 's|@@VERSION@@|%{dist_version}|g' Fedora-Legal-README.txt
%build
%install
install -d $RPM_BUILD_ROOT/etc
echo "Fedora release %{version} (%{release_name})" > $RPM_BUILD_ROOT/etc/fedora-release
echo "cpe:/o:fedoraproject:fedora:%{version}" > $RPM_BUILD_ROOT/etc/system-release-cpe
# Symlink the -release files
ln -s fedora-release $RPM_BUILD_ROOT/etc/redhat-release
ln -s fedora-release $RPM_BUILD_ROOT/etc/system-release
# Create the common os-release file
install -d $RPM_BUILD_ROOT/usr/lib/os.release.d/
cat << EOF >>$RPM_BUILD_ROOT/usr/lib/os.release.d/os-release-fedora
NAME=Fedora
VERSION="%{dist_version} (%{release_name})"
ID=fedora
VERSION_ID=%{dist_version}
PRETTY_NAME="Fedora %{dist_version} (%{release_name})"
ANSI_COLOR="0;34"
CPE_NAME="cpe:/o:fedoraproject:fedora:%{dist_version}"
HOME_URL="https://fedoraproject.org/;
BUG_REPORT_URL="https://bugzilla.redhat.com/;
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=%{bug_version}
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=%{bug_version}
PRIVACY_POLICY_URL=https://fedoraproject.org/wiki/Legal:PrivacyPolicy
EOF
# Create the common /etc/issue
echo "\S" > $RPM_BUILD_ROOT/usr/lib/os.release.d/issue-fedora
echo "Kernel \r on an \m (\l)" >> $RPM_BUILD_ROOT/usr/lib/os.release.d/issue-fedora
echo >> $RPM_BUILD_ROOT/usr/lib/os.release.d/issue-fedora
# Create /etc/issue.net
echo "\S" > $RPM_BUILD_ROOT/usr/lib/issue.net
echo "Kernel \r on an \m (\l)" >> $RPM_BUILD_ROOT/usr/lib/issue.net
ln -s ../usr/lib/issue.net $RPM_BUILD_ROOT/etc/issue.net
# Create os-release and issue files for the different editions
# Cloud
cp -p $RPM_BUILD_ROOT/usr/lib/os.release.d/os-release-fedora \
$RPM_BUILD_ROOT/usr/lib/os.release.d/os-release-cloud
echo "VARIANT=\"Cloud Edition\"" >> $RPM_BUILD_ROOT/usr/lib/os.release.d/os-release-cloud
echo "VARIANT_ID=cloud" >> $RPM_BUILD_ROOT/usr/lib/os.release.d/os-release-cloud
sed -i -e "s|(%{release_name})|(Cloud Edition)|g" $RPM_BUILD_ROOT/usr/lib/os.release.d/os-release-cloud
# Server
cp -p $RPM_BUILD_ROOT/usr/lib/os.release.d/os-release-fedora \
$RPM_BUILD_ROOT/usr/lib/os.release.d/os-release-server
echo "VARIANT=\"Server Edition\"" >>
Re: [HELP NEEDED] LUA expert to help convert fedora-release %post scripts
On 03/03/2016 05:55 PM, Florian Weimer wrote:
* Stephen Gallagher:
On 03/03/2016 10:22 AM, Florian Weimer wrote:
On 03/03/2016 04:00 PM, Stephen Gallagher wrote:
So what I am looking for is someone who is fluent in LUA to help me convert
these scripts over so that they can run entirely under the built-in LUA
interpreter of RPM and eliminate this problem.
I know that the language is spelled “Lua”, not “LUA”. Not sure if
that's enough qualification.
The fundamental question is whether you want to preserve this script as
a Lua script, for running outside of RPM. If not, we can
constant-propagate the command line flags into the script and simplify
it somewhat.
The ideal case is for it to be usable by the end-user to change the
Edition (or, more commonly, assign one if it's non-product at the
moment). That said, I'm open to treating that as a nice-to-have and
fixing just the install/upgrade cases right now.
It's possible to maintain two scripts if necessary. It is what we are
doing for the /etc/localtime update in Red Hat Enterprise Linux 6.
tzdata has a Lua implementation as a %post scriptlet, and glibc
provides a C implementation for use by system administrators.
I asked because a realistic getopt would be fairly involved to
reimplement in pure Lua. (There must be countless implementations of
that already, but I'm not sure if we want to add another dependency,
or lift an implementation from some wiki page.) The rest of the script
seems quite doable. I'll take a stab at it later today if no one else
shows up.
Note that the script would have to run under the RPM Lua interpreter,
the plain Lua interpreter does not provide some required functionality
(such as posix.files function). And you cannot run the script from a
file system path, you have to put it directly into the spec file.
So all the content has to be inline, or we can create a common
script/function and call it multiple times?
We can inline the file at build time using Lua scripting, I think.
You can %include files into spec, and also you can pull scripts contents
from a file with -f option to scriptlets, eg %post -f %{SOURCE5}
- Panu -
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: [HELP NEEDED] LUA expert to help convert fedora-release %post scripts
On 03/03/2016 10:55 AM, Florian Weimer wrote: > * Stephen Gallagher: > >> On 03/03/2016 10:22 AM, Florian Weimer wrote: >>> On 03/03/2016 04:00 PM, Stephen Gallagher wrote: >>> So what I am looking for is someone who is fluent in LUA to help me convert these scripts over so that they can run entirely under the built-in LUA interpreter of RPM and eliminate this problem. >>> >>> I know that the language is spelled “Lua”, not “LUA”. Not sure if >>> that's enough qualification. >>> >>> The fundamental question is whether you want to preserve this script as >>> a Lua script, for running outside of RPM. If not, we can >>> constant-propagate the command line flags into the script and simplify >>> it somewhat. >>> >> >> The ideal case is for it to be usable by the end-user to change the >> Edition (or, more commonly, assign one if it's non-product at the >> moment). That said, I'm open to treating that as a nice-to-have and >> fixing just the install/upgrade cases right now. > > It's possible to maintain two scripts if necessary. It is what we are > doing for the /etc/localtime update in Red Hat Enterprise Linux 6. > tzdata has a Lua implementation as a %post scriptlet, and glibc > provides a C implementation for use by system administrators. > > I asked because a realistic getopt would be fairly involved to > reimplement in pure Lua. (There must be countless implementations of > that already, but I'm not sure if we want to add another dependency, > or lift an implementation from some wiki page.) The rest of the script > seems quite doable. I'll take a stab at it later today if no one else > shows up. > I have no problems maintaining both scripts; I can just install the current bash script as-is and just keep them in sync if we make changes. If we do this right, changes should be extremely rare. Thank you for your help. >>> Note that the script would have to run under the RPM Lua interpreter, >>> the plain Lua interpreter does not provide some required functionality >>> (such as posix.files function). And you cannot run the script from a >>> file system path, you have to put it directly into the spec file. >>> >> >> So all the content has to be inline, or we can create a common >> script/function and call it multiple times? > > We can inline the file at build time using Lua scripting, I think. > OK signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: [HELP NEEDED] LUA expert to help convert fedora-release %post scripts
* Stephen Gallagher: > On 03/03/2016 10:22 AM, Florian Weimer wrote: >> On 03/03/2016 04:00 PM, Stephen Gallagher wrote: >> >>> So what I am looking for is someone who is fluent in LUA to help me convert >>> these scripts over so that they can run entirely under the built-in LUA >>> interpreter of RPM and eliminate this problem. >> >> I know that the language is spelled “Lua”, not “LUA”. Not sure if >> that's enough qualification. >> >> The fundamental question is whether you want to preserve this script as >> a Lua script, for running outside of RPM. If not, we can >> constant-propagate the command line flags into the script and simplify >> it somewhat. >> > > The ideal case is for it to be usable by the end-user to change the > Edition (or, more commonly, assign one if it's non-product at the > moment). That said, I'm open to treating that as a nice-to-have and > fixing just the install/upgrade cases right now. It's possible to maintain two scripts if necessary. It is what we are doing for the /etc/localtime update in Red Hat Enterprise Linux 6. tzdata has a Lua implementation as a %post scriptlet, and glibc provides a C implementation for use by system administrators. I asked because a realistic getopt would be fairly involved to reimplement in pure Lua. (There must be countless implementations of that already, but I'm not sure if we want to add another dependency, or lift an implementation from some wiki page.) The rest of the script seems quite doable. I'll take a stab at it later today if no one else shows up. >> Note that the script would have to run under the RPM Lua interpreter, >> the plain Lua interpreter does not provide some required functionality >> (such as posix.files function). And you cannot run the script from a >> file system path, you have to put it directly into the spec file. >> > > So all the content has to be inline, or we can create a common > script/function and call it multiple times? We can inline the file at build time using Lua scripting, I think. Florian -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: [HELP NEEDED] LUA expert to help convert fedora-release %post scripts
On 03/03/2016 10:22 AM, Florian Weimer wrote: > On 03/03/2016 04:00 PM, Stephen Gallagher wrote: > >> So what I am looking for is someone who is fluent in LUA to help me convert >> these scripts over so that they can run entirely under the built-in LUA >> interpreter of RPM and eliminate this problem. > > I know that the language is spelled “Lua”, not “LUA”. Not sure if > that's enough qualification. > > The fundamental question is whether you want to preserve this script as > a Lua script, for running outside of RPM. If not, we can > constant-propagate the command line flags into the script and simplify > it somewhat. > The ideal case is for it to be usable by the end-user to change the Edition (or, more commonly, assign one if it's non-product at the moment). That said, I'm open to treating that as a nice-to-have and fixing just the install/upgrade cases right now. > Note that the script would have to run under the RPM Lua interpreter, > the plain Lua interpreter does not provide some required functionality > (such as posix.files function). And you cannot run the script from a > file system path, you have to put it directly into the spec file. > So all the content has to be inline, or we can create a common script/function and call it multiple times? signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: [HELP NEEDED] LUA expert to help convert fedora-release %post scripts
On 03/03/2016 04:00 PM, Stephen Gallagher wrote: > So what I am looking for is someone who is fluent in LUA to help me convert > these scripts over so that they can run entirely under the built-in LUA > interpreter of RPM and eliminate this problem. I know that the language is spelled “Lua”, not “LUA”. Not sure if that's enough qualification. The fundamental question is whether you want to preserve this script as a Lua script, for running outside of RPM. If not, we can constant-propagate the command line flags into the script and simplify it somewhat. Note that the script would have to run under the RPM Lua interpreter, the plain Lua interpreter does not provide some required functionality (such as posix.files function). And you cannot run the script from a file system path, you have to put it directly into the spec file. Florian -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
[HELP NEEDED] LUA expert to help convert fedora-release %post scripts
As part of efforts in Fedora 24 to address certain issues with the
edition-specific fedora-release content (such as /etc/os-release, /etc/issues
and edition-specific presets), I built a moderately complex series of bash
scripts to run in %post and %posttrans to ensure that all of the right files
were symlinked in the correct places.
Unfortunately, the result here is that %post and %posttrans for fedora-release
now requires both bash and coreutils to function properly, and this introduces a
cyclical dependency. It works properly on upgrades of realistic systems (all of
which have bash and coreutils on them), but it introduces issues with mock and
minimalistic systems on installation.
So what I am looking for is someone who is fluent in LUA to help me convert
these scripts over so that they can run entirely under the built-in LUA
interpreter of RPM and eliminate this problem.
This is a fairly urgent issue, as it may cause blocking issues for Fedora 24
installations. So if you think you can help, please respond promptly.
I'm attaching the current fedora-release.spec and convert-to-edition bash script
for perusal.
#!/bin/bash
# Simple script to set up Edition defaults for Fedora
OPTIND=1
VARIANT_FILE=/usr/lib/variant
# Defaults are set to provide the fewest suprises for anyone running this
# script manually to convert their own system. In nearly all cases, it should
# be possible to run `convert-to-edition -e ` and get expected results
# By default, install new packages to ensure that all the necessary files are
# available before symlinking. This must be skipped when running this file as
# part of an RPM scriptlet.
do_installation=1
# By default, do not modify the enabled or disabled state of any service on the
# system. This should only be done when this script is run as part of system
# installation or if the user is certain that they want to apply the changes to
# the presets to their system.
enable_presets=0
exit_usage() {
echo "Usage: convert-to-edition [options] -e
cloud|non-edition|server|workstation"
echo "Options:"
echo "-e: The edition to install (cloud, non-edition, server or
workstation)"
echo "-i: Skip installing additional files and just update symlinks"
echo "-p: Also enable newly-added systemd presets"
exit 1
}
while getopts "e:ihp" opt; do
case "$opt" in
e)
EDITION=$OPTARG
;;
i)
do_installation=0
;;
p)
enable_presets=1
;;
h)
exit_usage
;;
esac
done
# None of the actions below can be run by a non-root user
if [[ $EUID -ne 0 ]]; then
echo "This script must be run as root" 1>&2
exit 1
fi
case $EDITION in
cloud)
if [ $do_installation -gt 0 ]; then
echo "Installing Fedora Cloud Packages"
dnf install -y fedora-release-cloud
fi
echo "VARIANT_ID=cloud" > $VARIANT_FILE
# Ensure that the os-release file is pointing to the correct version
ln -sf ./os.release.d/os-release-cloud /usr/lib/os-release || :
# Ensure that the issue file is pointing to the correct version
ln -sf ./os.release.d/issue-fedora /usr/lib/issue
# Remove any presets from other Editions.
rm -f /usr/lib/systemd/system-preset/80-*.preset
;;
non-edition)
echo "VARIANT_ID=nonproduct" > $VARIANT_FILE
# Ensure that the os-release file is pointing to the correct version
ln -sf ./os.release.d/os-release-fedora /usr/lib/os-release || :
# Ensure that the issue file is pointing to the correct version
ln -sf ./os.release.d/issue-fedora /usr/lib/issue
# Remove any presets from other Editions.
rm -f /usr/lib/systemd/system-preset/80-*.preset
;;
server)
if [ $do_installation -gt 0 ]; then
echo "Installing Fedora Server Packages"
dnf install -y fedora-release-server
fi
echo "VARIANT_ID=server" > $VARIANT_FILE
# Ensure that the os-release and issue files are pointing to the correct
# version
ln -sf ./os.release.d/os-release-server /usr/lib/os-release
ln -sf ./os.release.d/issue-server /usr/lib/issue
# Remove any presets from other Editions. This should always be a no-op,
# but it's good to be explicit.
# We reserve 80-*.preset for Editions
rm -f /usr/lib/systemd/system-preset/80-*.preset
# Symlink in the proper preset
ln -sf ../../os.release.d/presets/80-server.preset \
/usr/lib/systemd/system-preset/80-server.preset
if [ $enable_presets -gt 0 ]; then
# Enable new units specified by presets
units=$(sed -n 's/^enable//p' \
< /usr/lib/systemd/system-preset/80-server.preset)
/usr/bin/systemctl preset $units >/dev/null 2>&1 || :
# Disable new units specified by presets
units=$(sed -n 's/^disable//p' \
< /usr/lib/systemd/system-preset/80-server.preset)
/usr/bin/systemctl preset $units >/dev/null 2>&1 || :
fi
;;
workstation)
