| 2020-07-22 21:11:48 |
Andreas Hasenack |
bug |
|
|
added bug |
| 2020-07-22 21:12:51 |
Andreas Hasenack |
bug task added |
|
ubuntu-meta (Ubuntu) |
|
| 2020-07-22 21:13:08 |
Andreas Hasenack |
nominated for series |
|
Ubuntu Groovy |
|
| 2020-07-22 21:13:08 |
Andreas Hasenack |
bug task added |
|
base-files (Ubuntu Groovy) |
|
| 2020-07-22 21:13:08 |
Andreas Hasenack |
bug task added |
|
ubuntu-meta (Ubuntu Groovy) |
|
| 2020-07-22 21:13:08 |
Andreas Hasenack |
nominated for series |
|
Ubuntu Xenial |
|
| 2020-07-22 21:13:08 |
Andreas Hasenack |
bug task added |
|
base-files (Ubuntu Xenial) |
|
| 2020-07-22 21:13:08 |
Andreas Hasenack |
bug task added |
|
ubuntu-meta (Ubuntu Xenial) |
|
| 2020-07-22 21:13:08 |
Andreas Hasenack |
nominated for series |
|
Ubuntu Bionic |
|
| 2020-07-22 21:13:08 |
Andreas Hasenack |
bug task added |
|
base-files (Ubuntu Bionic) |
|
| 2020-07-22 21:13:08 |
Andreas Hasenack |
bug task added |
|
ubuntu-meta (Ubuntu Bionic) |
|
| 2020-07-22 21:13:08 |
Andreas Hasenack |
nominated for series |
|
Ubuntu Focal |
|
| 2020-07-22 21:13:08 |
Andreas Hasenack |
bug task added |
|
base-files (Ubuntu Focal) |
|
| 2020-07-22 21:13:08 |
Andreas Hasenack |
bug task added |
|
ubuntu-meta (Ubuntu Focal) |
|
| 2020-07-22 21:13:34 |
Andreas Hasenack |
base-files (Ubuntu Xenial): assignee |
|
Andreas Hasenack (ahasenack) |
|
| 2020-07-22 21:13:52 |
Andreas Hasenack |
base-files (Ubuntu Bionic): assignee |
|
Andreas Hasenack (ahasenack) |
|
| 2020-07-22 21:14:00 |
Andreas Hasenack |
base-files (Ubuntu Focal): assignee |
|
Andreas Hasenack (ahasenack) |
|
| 2020-07-22 21:14:04 |
Andreas Hasenack |
ubuntu-meta (Ubuntu Xenial): assignee |
|
Andreas Hasenack (ahasenack) |
|
| 2020-07-22 21:14:09 |
Andreas Hasenack |
ubuntu-meta (Ubuntu Bionic): assignee |
|
Andreas Hasenack (ahasenack) |
|
| 2020-07-22 21:14:12 |
Andreas Hasenack |
ubuntu-meta (Ubuntu Focal): assignee |
|
Andreas Hasenack (ahasenack) |
|
| 2020-07-22 21:14:15 |
Andreas Hasenack |
ubuntu-meta (Ubuntu Groovy): assignee |
|
Andreas Hasenack (ahasenack) |
|
| 2020-07-22 21:16:14 |
Andreas Hasenack |
base-files (Ubuntu Xenial): status |
New |
In Progress |
|
| 2020-07-22 21:16:18 |
Andreas Hasenack |
base-files (Ubuntu Bionic): status |
New |
In Progress |
|
| 2020-07-22 21:16:23 |
Andreas Hasenack |
base-files (Ubuntu Focal): status |
New |
In Progress |
|
| 2020-07-22 21:16:27 |
Andreas Hasenack |
ubuntu-meta (Ubuntu Xenial): status |
New |
In Progress |
|
| 2020-07-22 21:16:32 |
Andreas Hasenack |
ubuntu-meta (Ubuntu Bionic): status |
New |
In Progress |
|
| 2020-07-22 21:16:36 |
Andreas Hasenack |
ubuntu-meta (Ubuntu Focal): status |
New |
In Progress |
|
| 2020-07-22 21:16:41 |
Andreas Hasenack |
ubuntu-meta (Ubuntu Groovy): status |
New |
In Progress |
|
| 2020-07-22 21:28:09 |
Kai Kasurinen |
bug |
|
|
added subscriber Kai Kasurinen |
| 2020-07-30 18:02:23 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/base-files/+git/base-files/+merge/388400 |
|
| 2020-07-30 18:06:43 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu-seeds/+git/ubuntu-seeds/+merge/388402 |
|
| 2020-07-30 18:07:40 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu-seeds/+git/ubuntu-seeds/+merge/388403 |
|
| 2020-08-06 17:10:48 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/base-files/+git/base-files/+merge/388835 |
|
| 2020-08-06 21:50:13 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/base-files/+git/base-files/+merge/388848 |
|
| 2020-08-07 19:33:33 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/base-files/+git/base-files/+merge/388922 |
|
| 2020-08-12 17:55:28 |
Andreas Hasenack |
description |
The motd-news script is largely useless for desktop users, as they rarely login via a text console. It makes more sense for server users.
We can use package dependencies to have the motd-news script enabled on servers, but disabled on desktops, and still handle upgrades. This is the plan:
- move /etc/default/motd-news from base-files into a NEW package (motd-news-config)
- have ubuntu-server depend on motd-news-config (or recommends)
- have base-files break current ubuntu-server, so that if base-files if upgraded and ubuntu-server is installed, ubuntu-server will also be upgraded to the new version which has the depends (or recommends) on motd-news-config
Care must be taken to preserve a changed /etc/default/motd-news when the upgrade installs the new motd-news-config package. For example, on a server that has set ENABLED=0 in /etc/default/motd-news and upgrades to the new base-files and ubuntu-server, and gets the new motd-config-news package, ENABLED=0 must remain set. |
[Impact]
The motd-news script is largely useless for desktop users, as they rarely login via a text console. It makes more sense for server users.
We can use package dependencies to have the motd-news script enabled on servers, but disabled on desktops, and still handle upgrades. This is the plan:
- move /etc/default/motd-news from base-files into a NEW package (motd-news-config)
- have ubuntu-server depend on motd-news-config (or recommends)
- have base-files break current ubuntu-server, so that if base-files if upgraded and ubuntu-server is installed, ubuntu-server will also be upgraded to the new version which has the depends (or recommends) on motd-news-config
Care must be taken to preserve a changed /etc/default/motd-news when the upgrade installs the new motd-news-config package. For example, on a server that has set ENABLED=0 in /etc/default/motd-news and upgrades to the new base-files and ubuntu-server, and gets the new motd-config-news package, ENABLED=0 must remain set.
[Test Case]
a) base-files installed, ubuntu-server installed, unmodified /e/d/motd-news
apt install base-files
- upgrades ubuntu-server
- installs motd-news-config
- /e/d/motd-news remains, motd-news remains enabled
b) base-files installed, ubuntu-server installed, modified /e/d/motd-news
apt install base-files
- upgrades ubuntu-server
- installs motd-news-config
- /e/d/motd-news remains with the original modification
c) base-files installed, ubuntu-server not installed, unmodified /e/d/motd-news
apt install base-files
- upgrades base-files
- removes /e/d/motd-news
- motd-news is disabled
d) base-files installed, ubuntu-server not installed, modified /e/d/motd-news
apt install base-files
- upgrades base-files
- /e/d/motd-news gets renamed to backup
- motd-news is disabled
e) removing motd-news-config will also remove ubuntu-server (since it's a depends, and not a recommends)
f) upgrading just ubuntu-server should pull motd-news-config in, and force-upgrade base-files
g) Removing motd-news-server leaves /e/d/motd-news around; purging motd-news-server removes the /e/d/motd-news config file
h) base-files installed, ubuntu-server installed, removed /e/d/motd-news
- apt install base-files
- upgrades base-files, upgrades ubuntu-server, installs motd-news-config
- /e/d/motd-news is installed with ENABLED=0
i) base-files installed, ubuntu-server NOT installed, removed e/d/motd-news
- apt install base-files
- base-files is upgraded
- no /e/d/motd-news is installed, motd-news remains disabled
[Regression Potential]
[Other Info]
Testcase (i) will leave around an empty /etc/default/motd-news.wasremoved file, created by the base-files postinst. This file is removed by the motd-news-config postinst, but since that package doesn't get installed in that particular scenario, the file remains. I toyed with the idea of adding an extra check to base-file's postinst, like this:
--- a/debian/postinst.in
+++ b/debian/postinst.in
@@ -133,7 +133,11 @@ motd_news_config="/etc/default/motd-news"
if [ ! -e ${motd_news_config} ]; then
if [ ! -e ${motd_news_config}.dpkg-remove ]; then
if [ ! -e ${motd_news_config}.dpkg-backup ]; then
- touch ${motd_news_config}.wasremoved
+ # The .wasremoved file only matters if ubuntu-server is installed,
+ # because that's what will pull in motd-news-config
+ if dpkg -l ubuntu-server 2>/dev/null | grep -q ^i; then
+ touch ${motd_news_config}.wasremoved
+ fi
fi
fi
fi
But deemed it too risky, and not worth further potential regressions. |
|
| 2020-08-12 17:57:11 |
Andreas Hasenack |
description |
[Impact]
The motd-news script is largely useless for desktop users, as they rarely login via a text console. It makes more sense for server users.
We can use package dependencies to have the motd-news script enabled on servers, but disabled on desktops, and still handle upgrades. This is the plan:
- move /etc/default/motd-news from base-files into a NEW package (motd-news-config)
- have ubuntu-server depend on motd-news-config (or recommends)
- have base-files break current ubuntu-server, so that if base-files if upgraded and ubuntu-server is installed, ubuntu-server will also be upgraded to the new version which has the depends (or recommends) on motd-news-config
Care must be taken to preserve a changed /etc/default/motd-news when the upgrade installs the new motd-news-config package. For example, on a server that has set ENABLED=0 in /etc/default/motd-news and upgrades to the new base-files and ubuntu-server, and gets the new motd-config-news package, ENABLED=0 must remain set.
[Test Case]
a) base-files installed, ubuntu-server installed, unmodified /e/d/motd-news
apt install base-files
- upgrades ubuntu-server
- installs motd-news-config
- /e/d/motd-news remains, motd-news remains enabled
b) base-files installed, ubuntu-server installed, modified /e/d/motd-news
apt install base-files
- upgrades ubuntu-server
- installs motd-news-config
- /e/d/motd-news remains with the original modification
c) base-files installed, ubuntu-server not installed, unmodified /e/d/motd-news
apt install base-files
- upgrades base-files
- removes /e/d/motd-news
- motd-news is disabled
d) base-files installed, ubuntu-server not installed, modified /e/d/motd-news
apt install base-files
- upgrades base-files
- /e/d/motd-news gets renamed to backup
- motd-news is disabled
e) removing motd-news-config will also remove ubuntu-server (since it's a depends, and not a recommends)
f) upgrading just ubuntu-server should pull motd-news-config in, and force-upgrade base-files
g) Removing motd-news-server leaves /e/d/motd-news around; purging motd-news-server removes the /e/d/motd-news config file
h) base-files installed, ubuntu-server installed, removed /e/d/motd-news
- apt install base-files
- upgrades base-files, upgrades ubuntu-server, installs motd-news-config
- /e/d/motd-news is installed with ENABLED=0
i) base-files installed, ubuntu-server NOT installed, removed e/d/motd-news
- apt install base-files
- base-files is upgraded
- no /e/d/motd-news is installed, motd-news remains disabled
[Regression Potential]
[Other Info]
Testcase (i) will leave around an empty /etc/default/motd-news.wasremoved file, created by the base-files postinst. This file is removed by the motd-news-config postinst, but since that package doesn't get installed in that particular scenario, the file remains. I toyed with the idea of adding an extra check to base-file's postinst, like this:
--- a/debian/postinst.in
+++ b/debian/postinst.in
@@ -133,7 +133,11 @@ motd_news_config="/etc/default/motd-news"
if [ ! -e ${motd_news_config} ]; then
if [ ! -e ${motd_news_config}.dpkg-remove ]; then
if [ ! -e ${motd_news_config}.dpkg-backup ]; then
- touch ${motd_news_config}.wasremoved
+ # The .wasremoved file only matters if ubuntu-server is installed,
+ # because that's what will pull in motd-news-config
+ if dpkg -l ubuntu-server 2>/dev/null | grep -q ^i; then
+ touch ${motd_news_config}.wasremoved
+ fi
fi
fi
fi
But deemed it too risky, and not worth further potential regressions. |
[Impact]
The motd-news script is largely useless for desktop users, as they rarely login via a text console. It makes more sense for server users.
We can use package dependencies to have the motd-news script enabled on servers, but disabled on desktops, and still handle upgrades. This is the plan:
- move /etc/default/motd-news from base-files into a new binary package (motd-news-config, produced by src:base-files)
- have ubuntu-server depend on motd-news-config
- have base-files break current ubuntu-server, so that if base-files if upgraded and ubuntu-server is installed, ubuntu-server will also be upgraded to the new version which has the depends on motd-news-config
Care must be taken to preserve a changed /etc/default/motd-news when the upgrade installs the new motd-news-config package. For example, on a server that has set ENABLED=0 in /etc/default/motd-news and upgrades to the new base-files and ubuntu-server, and gets the new motd-config-news package, ENABLED=0 must remain set.
[Test Case]
a) base-files installed, ubuntu-server installed, unmodified /e/d/motd-news
apt install base-files
- upgrades ubuntu-server
- installs motd-news-config
- /e/d/motd-news remains, motd-news remains enabled
b) base-files installed, ubuntu-server installed, modified /e/d/motd-news
apt install base-files
- upgrades ubuntu-server
- installs motd-news-config
- /e/d/motd-news remains with the original modification
c) base-files installed, ubuntu-server not installed, unmodified /e/d/motd-news
apt install base-files
- upgrades base-files
- removes /e/d/motd-news
- motd-news is disabled
d) base-files installed, ubuntu-server not installed, modified /e/d/motd-news
apt install base-files
- upgrades base-files
- /e/d/motd-news gets renamed to backup
- motd-news is disabled
e) removing motd-news-config will also remove ubuntu-server (since it's a depends, and not a recommends)
f) upgrading just ubuntu-server should pull motd-news-config in, and force-upgrade base-files
g) Removing motd-news-server leaves /e/d/motd-news around; purging motd-news-server removes the /e/d/motd-news config file
h) base-files installed, ubuntu-server installed, removed /e/d/motd-news
- apt install base-files
- upgrades base-files, upgrades ubuntu-server, installs motd-news-config
- /e/d/motd-news is installed with ENABLED=0
i) base-files installed, ubuntu-server NOT installed, removed e/d/motd-news
- apt install base-files
- base-files is upgraded
- no /e/d/motd-news is installed, motd-news remains disabled
[Regression Potential]
[Other Info]
Testcase (i) will leave around an empty /etc/default/motd-news.wasremoved file, created by the base-files postinst. This file is removed by the motd-news-config postinst, but since that package doesn't get installed in that particular scenario, the file remains. I toyed with the idea of adding an extra check to base-file's postinst, like this:
--- a/debian/postinst.in
+++ b/debian/postinst.in
@@ -133,7 +133,11 @@ motd_news_config="/etc/default/motd-news"
if [ ! -e ${motd_news_config} ]; then
if [ ! -e ${motd_news_config}.dpkg-remove ]; then
if [ ! -e ${motd_news_config}.dpkg-backup ]; then
- touch ${motd_news_config}.wasremoved
+ # The .wasremoved file only matters if ubuntu-server is installed,
+ # because that's what will pull in motd-news-config
+ if dpkg -l ubuntu-server 2>/dev/null | grep -q ^i; then
+ touch ${motd_news_config}.wasremoved
+ fi
fi
fi
fi
But deemed it too risky, and not worth further potential regressions. |
|
| 2020-08-12 18:20:45 |
Andreas Hasenack |
description |
[Impact]
The motd-news script is largely useless for desktop users, as they rarely login via a text console. It makes more sense for server users.
We can use package dependencies to have the motd-news script enabled on servers, but disabled on desktops, and still handle upgrades. This is the plan:
- move /etc/default/motd-news from base-files into a new binary package (motd-news-config, produced by src:base-files)
- have ubuntu-server depend on motd-news-config
- have base-files break current ubuntu-server, so that if base-files if upgraded and ubuntu-server is installed, ubuntu-server will also be upgraded to the new version which has the depends on motd-news-config
Care must be taken to preserve a changed /etc/default/motd-news when the upgrade installs the new motd-news-config package. For example, on a server that has set ENABLED=0 in /etc/default/motd-news and upgrades to the new base-files and ubuntu-server, and gets the new motd-config-news package, ENABLED=0 must remain set.
[Test Case]
a) base-files installed, ubuntu-server installed, unmodified /e/d/motd-news
apt install base-files
- upgrades ubuntu-server
- installs motd-news-config
- /e/d/motd-news remains, motd-news remains enabled
b) base-files installed, ubuntu-server installed, modified /e/d/motd-news
apt install base-files
- upgrades ubuntu-server
- installs motd-news-config
- /e/d/motd-news remains with the original modification
c) base-files installed, ubuntu-server not installed, unmodified /e/d/motd-news
apt install base-files
- upgrades base-files
- removes /e/d/motd-news
- motd-news is disabled
d) base-files installed, ubuntu-server not installed, modified /e/d/motd-news
apt install base-files
- upgrades base-files
- /e/d/motd-news gets renamed to backup
- motd-news is disabled
e) removing motd-news-config will also remove ubuntu-server (since it's a depends, and not a recommends)
f) upgrading just ubuntu-server should pull motd-news-config in, and force-upgrade base-files
g) Removing motd-news-server leaves /e/d/motd-news around; purging motd-news-server removes the /e/d/motd-news config file
h) base-files installed, ubuntu-server installed, removed /e/d/motd-news
- apt install base-files
- upgrades base-files, upgrades ubuntu-server, installs motd-news-config
- /e/d/motd-news is installed with ENABLED=0
i) base-files installed, ubuntu-server NOT installed, removed e/d/motd-news
- apt install base-files
- base-files is upgraded
- no /e/d/motd-news is installed, motd-news remains disabled
[Regression Potential]
[Other Info]
Testcase (i) will leave around an empty /etc/default/motd-news.wasremoved file, created by the base-files postinst. This file is removed by the motd-news-config postinst, but since that package doesn't get installed in that particular scenario, the file remains. I toyed with the idea of adding an extra check to base-file's postinst, like this:
--- a/debian/postinst.in
+++ b/debian/postinst.in
@@ -133,7 +133,11 @@ motd_news_config="/etc/default/motd-news"
if [ ! -e ${motd_news_config} ]; then
if [ ! -e ${motd_news_config}.dpkg-remove ]; then
if [ ! -e ${motd_news_config}.dpkg-backup ]; then
- touch ${motd_news_config}.wasremoved
+ # The .wasremoved file only matters if ubuntu-server is installed,
+ # because that's what will pull in motd-news-config
+ if dpkg -l ubuntu-server 2>/dev/null | grep -q ^i; then
+ touch ${motd_news_config}.wasremoved
+ fi
fi
fi
fi
But deemed it too risky, and not worth further potential regressions. |
[Impact]
The motd-news script is largely useless for desktop users, as they rarely login via a text console. It makes more sense for server users.
We can use package dependencies to have the motd-news script enabled on servers, but disabled on desktops, and still handle upgrades. This is the plan:
- move /etc/default/motd-news from base-files into a new binary package (motd-news-config, produced by src:base-files)
- have ubuntu-server depend on motd-news-config
- have base-files break current ubuntu-server, so that if base-files if upgraded and ubuntu-server is installed, ubuntu-server will also be upgraded to the new version which has the depends on motd-news-config
Care must be taken to preserve a changed /etc/default/motd-news when the upgrade installs the new motd-news-config package. For example, on a server that has set ENABLED=0 in /etc/default/motd-news and upgrades to the new base-files and ubuntu-server, and gets the new motd-config-news package, ENABLED=0 must remain set.
[Test Case]
a) base-files installed, ubuntu-server installed, unmodified /e/d/motd-news
apt install base-files
- upgrades ubuntu-server
- installs motd-news-config
- /e/d/motd-news remains, motd-news remains enabled
b) base-files installed, ubuntu-server installed, modified /e/d/motd-news
apt install base-files
- upgrades ubuntu-server
- installs motd-news-config
- /e/d/motd-news remains with the original modification
c) base-files installed, ubuntu-server not installed, unmodified /e/d/motd-news
apt install base-files
- upgrades base-files
- removes /e/d/motd-news
- motd-news is disabled
d) base-files installed, ubuntu-server not installed, modified /e/d/motd-news
apt install base-files
- upgrades base-files
- /e/d/motd-news gets renamed to backup
- motd-news is disabled
e) removing motd-news-config will also remove ubuntu-server (since it's a depends, and not a recommends)
f) upgrading just ubuntu-server should pull motd-news-config in, and force-upgrade base-files
g) Removing motd-news-server leaves /e/d/motd-news around; purging motd-news-server removes the /e/d/motd-news config file
h) base-files installed, ubuntu-server installed, removed /e/d/motd-news
- apt install base-files
- upgrades base-files, upgrades ubuntu-server, installs motd-news-config
- /e/d/motd-news is installed with ENABLED=0
i) base-files installed, ubuntu-server NOT installed, removed e/d/motd-news
- apt install base-files
- base-files is upgraded
- no /e/d/motd-news is installed, motd-news remains disabled
[Regression Potential]
This update is about config file ownership transfer: /e/d/motd-news belonged to base-files, now it belongs to motd-news-config. We tried to handle two important cases here:
a) /e/d/motd-news config was changed while it belonged to base-files. For example, an user could have set ENABLED=0. We need to transfer that change to the motd-news-config package when it is installed, otherwise this SRU would jsut re-enabled motd-news. This is handled in d/motd-news-config.postinst's configure case.
b) /e/d/motd-news config file was *removed* while it belonged to base-files. In such a case, a normal upgrade of the package (base-files in this example) would not reinstate the file. Much less this upgrade here, which has an explicit rm_conffile maintscript-helper for it. But the motd-news-config package that could be installed in the transaction would place the default config file back, and the default is ENABLED=1. Thus, a system that had motd-news disabled via removing the config file would now have it re-enabled after the upgrade.
This was trickier to handle, and we do it in base-files's postinst and motd-news-config's postinst. The drawback is that in one scenario, where just base-files is upgraded, there will be a /e/d/motd-news.wasremoved leftover empty file (see "other info" below for details).
In general, the regression risks here are:
- have motd-news enabled again on a system where it was previously disabled. We tried to envision two ways it would have been disabled (set ENABLED=0, and remove the config file). There are probably others
- differences in dpkg and/or debhelper behavior in older ubuntu releases leading to unexpected results (should be covered by the test cases from this SRU)
- xenial in particular is trickier, because src:base-files there does NOT use debhelper, so many of the things we take for granted have to be done by hand
- have some sort of dpkg postinst or dependency error because of unpredicted scenarios. Certain assumptions are being made, like the renames that dpkg-maintscript-helper does, and that the filename /etc/default/motd-news.wasremoved that I'm touching and verifying is really mine and not something that was there already.
- the versions I'm breaking/replacing on, and using rm_conffiles on, must be exact. These are the versions today in the archive (2020-08-12):
base-files:
x: 9.4ubuntu4.12
b: 10.1ubuntu2.9
f: 11ubuntu5.1
g: 11ubuntu10
ubuntu-meta:
x: 1.361.4
b: 1.417.4
f: 1.450.1
g: 1.452
Which reflect in these relationships in the updated packages:
Groovy:
ubuntu-server 1.453:
Depends: motd-news-config
base-files 11ubuntu11:
Breaks: ubuntu-server (<< 1.453)
rm_conffile /etc/default/motd-news 11ubuntu11~ base-files
motd-news-config 11ubuntu11:
Breaks/Replaces: base-files (<< 11ubuntu11)
Focal:
ubuntu-server 1.450.2:
Depends: motd-news-config
base-files 11ubuntu5.2:
Breaks: ubuntu-server (<< 1.450.2)
rm_conffile /etc/default/motd-news 11ubuntu5.2~ base-files
motd-news-config 11ubuntu5.2:
Breaks/Replaces: base-files (<< 11ubuntu5.2)
Bionic:
ubuntu-server 1.417.5:
Depends: motd-news-config
base-files 10.1ubuntu2.10:
Breaks: ubuntu-server (<< 1.417.5)
rm_conffile /etc/default/motd-news 10.1ubuntu2.10~ base-files
motd-news-config 10.1ubuntu2.10:
Breaks/Replaces: base-files (<< 10.1ubuntu2.10)
Xenial:
ubuntu-server 1.361.5:
Depends: motd-news-config
base-files 9.4ubuntu4.13:
Breaks: ubuntu-server (<< 1.361.5)
rm_conffile /etc/default/motd-news 9.4ubuntu4.13~ base-files
motd-news-config 9.4ubuntu4.13:
Breaks/Replaces: base-files (<< 9.4ubuntu4.13)
[Other Info]
a) Testcase (i) will leave around an empty /etc/default/motd-news.wasremoved file, created by the base-files postinst. This file is removed by the motd-news-config postinst, but since that package doesn't get installed in that particular scenario, the file remains. I toyed with the idea of adding an extra check to base-file's postinst, like this:
--- a/debian/postinst.in
+++ b/debian/postinst.in
@@ -133,7 +133,11 @@ motd_news_config="/etc/default/motd-news"
if [ ! -e ${motd_news_config} ]; then
if [ ! -e ${motd_news_config}.dpkg-remove ]; then
if [ ! -e ${motd_news_config}.dpkg-backup ]; then
- touch ${motd_news_config}.wasremoved
+ # The .wasremoved file only matters if ubuntu-server is installed,
+ # because that's what will pull in motd-news-config
+ if dpkg -l ubuntu-server 2>/dev/null | grep -q ^i; then
+ touch ${motd_news_config}.wasremoved
+ fi
fi
fi
fi
But deemed it too risky, and not worth further potential regressions.
b) Currently the xenial cloud images, with the exception of the AWS one, do not have ubuntu-server installed. This means that this SRU will disable motd-news on them, unless ubuntu-server was manually installed for some reason. This includes LXD xenial images as well. |
|
| 2020-08-12 18:26:51 |
Andreas Hasenack |
description |
[Impact]
The motd-news script is largely useless for desktop users, as they rarely login via a text console. It makes more sense for server users.
We can use package dependencies to have the motd-news script enabled on servers, but disabled on desktops, and still handle upgrades. This is the plan:
- move /etc/default/motd-news from base-files into a new binary package (motd-news-config, produced by src:base-files)
- have ubuntu-server depend on motd-news-config
- have base-files break current ubuntu-server, so that if base-files if upgraded and ubuntu-server is installed, ubuntu-server will also be upgraded to the new version which has the depends on motd-news-config
Care must be taken to preserve a changed /etc/default/motd-news when the upgrade installs the new motd-news-config package. For example, on a server that has set ENABLED=0 in /etc/default/motd-news and upgrades to the new base-files and ubuntu-server, and gets the new motd-config-news package, ENABLED=0 must remain set.
[Test Case]
a) base-files installed, ubuntu-server installed, unmodified /e/d/motd-news
apt install base-files
- upgrades ubuntu-server
- installs motd-news-config
- /e/d/motd-news remains, motd-news remains enabled
b) base-files installed, ubuntu-server installed, modified /e/d/motd-news
apt install base-files
- upgrades ubuntu-server
- installs motd-news-config
- /e/d/motd-news remains with the original modification
c) base-files installed, ubuntu-server not installed, unmodified /e/d/motd-news
apt install base-files
- upgrades base-files
- removes /e/d/motd-news
- motd-news is disabled
d) base-files installed, ubuntu-server not installed, modified /e/d/motd-news
apt install base-files
- upgrades base-files
- /e/d/motd-news gets renamed to backup
- motd-news is disabled
e) removing motd-news-config will also remove ubuntu-server (since it's a depends, and not a recommends)
f) upgrading just ubuntu-server should pull motd-news-config in, and force-upgrade base-files
g) Removing motd-news-server leaves /e/d/motd-news around; purging motd-news-server removes the /e/d/motd-news config file
h) base-files installed, ubuntu-server installed, removed /e/d/motd-news
- apt install base-files
- upgrades base-files, upgrades ubuntu-server, installs motd-news-config
- /e/d/motd-news is installed with ENABLED=0
i) base-files installed, ubuntu-server NOT installed, removed e/d/motd-news
- apt install base-files
- base-files is upgraded
- no /e/d/motd-news is installed, motd-news remains disabled
[Regression Potential]
This update is about config file ownership transfer: /e/d/motd-news belonged to base-files, now it belongs to motd-news-config. We tried to handle two important cases here:
a) /e/d/motd-news config was changed while it belonged to base-files. For example, an user could have set ENABLED=0. We need to transfer that change to the motd-news-config package when it is installed, otherwise this SRU would jsut re-enabled motd-news. This is handled in d/motd-news-config.postinst's configure case.
b) /e/d/motd-news config file was *removed* while it belonged to base-files. In such a case, a normal upgrade of the package (base-files in this example) would not reinstate the file. Much less this upgrade here, which has an explicit rm_conffile maintscript-helper for it. But the motd-news-config package that could be installed in the transaction would place the default config file back, and the default is ENABLED=1. Thus, a system that had motd-news disabled via removing the config file would now have it re-enabled after the upgrade.
This was trickier to handle, and we do it in base-files's postinst and motd-news-config's postinst. The drawback is that in one scenario, where just base-files is upgraded, there will be a /e/d/motd-news.wasremoved leftover empty file (see "other info" below for details).
In general, the regression risks here are:
- have motd-news enabled again on a system where it was previously disabled. We tried to envision two ways it would have been disabled (set ENABLED=0, and remove the config file). There are probably others
- differences in dpkg and/or debhelper behavior in older ubuntu releases leading to unexpected results (should be covered by the test cases from this SRU)
- xenial in particular is trickier, because src:base-files there does NOT use debhelper, so many of the things we take for granted have to be done by hand
- have some sort of dpkg postinst or dependency error because of unpredicted scenarios. Certain assumptions are being made, like the renames that dpkg-maintscript-helper does, and that the filename /etc/default/motd-news.wasremoved that I'm touching and verifying is really mine and not something that was there already.
- the versions I'm breaking/replacing on, and using rm_conffiles on, must be exact. These are the versions today in the archive (2020-08-12):
base-files:
x: 9.4ubuntu4.12
b: 10.1ubuntu2.9
f: 11ubuntu5.1
g: 11ubuntu10
ubuntu-meta:
x: 1.361.4
b: 1.417.4
f: 1.450.1
g: 1.452
Which reflect in these relationships in the updated packages:
Groovy:
ubuntu-server 1.453:
Depends: motd-news-config
base-files 11ubuntu11:
Breaks: ubuntu-server (<< 1.453)
rm_conffile /etc/default/motd-news 11ubuntu11~ base-files
motd-news-config 11ubuntu11:
Breaks/Replaces: base-files (<< 11ubuntu11)
Focal:
ubuntu-server 1.450.2:
Depends: motd-news-config
base-files 11ubuntu5.2:
Breaks: ubuntu-server (<< 1.450.2)
rm_conffile /etc/default/motd-news 11ubuntu5.2~ base-files
motd-news-config 11ubuntu5.2:
Breaks/Replaces: base-files (<< 11ubuntu5.2)
Bionic:
ubuntu-server 1.417.5:
Depends: motd-news-config
base-files 10.1ubuntu2.10:
Breaks: ubuntu-server (<< 1.417.5)
rm_conffile /etc/default/motd-news 10.1ubuntu2.10~ base-files
motd-news-config 10.1ubuntu2.10:
Breaks/Replaces: base-files (<< 10.1ubuntu2.10)
Xenial:
ubuntu-server 1.361.5:
Depends: motd-news-config
base-files 9.4ubuntu4.13:
Breaks: ubuntu-server (<< 1.361.5)
rm_conffile /etc/default/motd-news 9.4ubuntu4.13~ base-files
motd-news-config 9.4ubuntu4.13:
Breaks/Replaces: base-files (<< 9.4ubuntu4.13)
[Other Info]
a) Testcase (i) will leave around an empty /etc/default/motd-news.wasremoved file, created by the base-files postinst. This file is removed by the motd-news-config postinst, but since that package doesn't get installed in that particular scenario, the file remains. I toyed with the idea of adding an extra check to base-file's postinst, like this:
--- a/debian/postinst.in
+++ b/debian/postinst.in
@@ -133,7 +133,11 @@ motd_news_config="/etc/default/motd-news"
if [ ! -e ${motd_news_config} ]; then
if [ ! -e ${motd_news_config}.dpkg-remove ]; then
if [ ! -e ${motd_news_config}.dpkg-backup ]; then
- touch ${motd_news_config}.wasremoved
+ # The .wasremoved file only matters if ubuntu-server is installed,
+ # because that's what will pull in motd-news-config
+ if dpkg -l ubuntu-server 2>/dev/null | grep -q ^i; then
+ touch ${motd_news_config}.wasremoved
+ fi
fi
fi
fi
But deemed it too risky, and not worth further potential regressions.
b) Currently the xenial cloud images, with the exception of the AWS one, do not have ubuntu-server installed. This means that this SRU will disable motd-news on them, unless ubuntu-server was manually installed for some reason. This includes LXD xenial images as well. |
[Impact]
The motd-news script is largely useless for desktop users, as they rarely login via a text console. It makes more sense for server users.
We can use package dependencies to have the motd-news script enabled on servers, but disabled on desktops, and still handle upgrades. This is the plan:
- move /etc/default/motd-news from base-files into a new binary package (motd-news-config, produced by src:base-files)
- have ubuntu-server depend on motd-news-config
- have base-files break current ubuntu-server, so that if base-files if upgraded and ubuntu-server is installed, ubuntu-server will also be upgraded to the new version which has the depends on motd-news-config
Care must be taken to preserve a changed /etc/default/motd-news when the upgrade installs the new motd-news-config package. For example, on a server that has set ENABLED=0 in /etc/default/motd-news and upgrades to the new base-files and ubuntu-server, and gets the new motd-config-news package, ENABLED=0 must remain set.
[Test Case]
a) base-files installed, ubuntu-server installed, unmodified /e/d/motd-news
apt install base-files
- upgrades ubuntu-server
- installs motd-news-config
- /e/d/motd-news remains, motd-news remains enabled
b) base-files installed, ubuntu-server installed, modified /e/d/motd-news
apt install base-files
- upgrades ubuntu-server
- installs motd-news-config
- /e/d/motd-news remains with the original modification
c) base-files installed, ubuntu-server not installed, unmodified /e/d/motd-news
apt install base-files
- upgrades base-files
- removes /e/d/motd-news
- motd-news is disabled
d) base-files installed, ubuntu-server not installed, modified /e/d/motd-news
apt install base-files
- upgrades base-files
- /e/d/motd-news gets renamed to backup
- motd-news is disabled
e) removing motd-news-config will also remove ubuntu-server (since it's a depends, and not a recommends)
f) upgrading just ubuntu-server should pull motd-news-config in, and force-upgrade base-files
g) Removing motd-news-server leaves /e/d/motd-news around; purging motd-news-server removes the /e/d/motd-news config file
h) base-files installed, ubuntu-server installed, removed /e/d/motd-news
- apt install base-files
- upgrades base-files, upgrades ubuntu-server, installs motd-news-config
- /e/d/motd-news is installed with ENABLED=0
i) base-files installed, ubuntu-server NOT installed, removed e/d/motd-news
- apt install base-files
- base-files is upgraded
- no /e/d/motd-news is installed, motd-news remains disabled
[Regression Potential]
This update is about config file ownership transfer: /e/d/motd-news belonged to base-files, now it belongs to motd-news-config. We tried to handle two important cases here:
a) /e/d/motd-news config was changed while it belonged to base-files. For example, an user could have set ENABLED=0. We need to transfer that change to the motd-news-config package when it is installed, otherwise this SRU would jsut re-enabled motd-news. This is handled in d/motd-news-config.postinst's configure case.
b) /e/d/motd-news config file was *removed* while it belonged to base-files. In such a case, a normal upgrade of the package (base-files in this example) would not reinstate the file. Much less this upgrade here, which has an explicit rm_conffile maintscript-helper for it. But the motd-news-config package that could be installed in the transaction would place the default config file back, and the default is ENABLED=1. Thus, a system that had motd-news disabled via removing the config file would now have it re-enabled after the upgrade.
This was trickier to handle, and we do it in base-files's postinst and motd-news-config's postinst. The drawback is that in one scenario, where just base-files is upgraded and /e/d/motd-news was manually removed by the user, there will be a /e/d/motd-news.wasremoved leftover empty file (see "other info" below for details).
In general, the regression risks here are:
- have motd-news enabled again on a system where it was previously disabled. We tried to envision two ways it would have been disabled (set ENABLED=0, and remove the config file). There are probably others
- differences in dpkg and/or debhelper behavior in older ubuntu releases leading to unexpected results (should be covered by the test cases from this SRU)
- xenial in particular is trickier, because src:base-files there does NOT use debhelper, so many of the things we take for granted have to be done by hand
- have some sort of dpkg postinst or dependency error because of unpredicted scenarios. Certain assumptions are being made, like the renames that dpkg-maintscript-helper does, and that the filename /etc/default/motd-news.wasremoved that I'm touching and verifying is really mine and not something that was there already.
- the versions I'm breaking/replacing on, and using rm_conffiles on, must be exact. These are the versions today in the archive (2020-08-12):
base-files:
x: 9.4ubuntu4.12
b: 10.1ubuntu2.9
f: 11ubuntu5.1
g: 11ubuntu10
ubuntu-meta:
x: 1.361.4
b: 1.417.4
f: 1.450.1
g: 1.452
Which reflect in these relationships in the updated packages:
Groovy:
ubuntu-server 1.453:
Depends: motd-news-config
base-files 11ubuntu11:
Breaks: ubuntu-server (<< 1.453)
rm_conffile /etc/default/motd-news 11ubuntu11~ base-files
motd-news-config 11ubuntu11:
Breaks/Replaces: base-files (<< 11ubuntu11)
Focal:
ubuntu-server 1.450.2:
Depends: motd-news-config
base-files 11ubuntu5.2:
Breaks: ubuntu-server (<< 1.450.2)
rm_conffile /etc/default/motd-news 11ubuntu5.2~ base-files
motd-news-config 11ubuntu5.2:
Breaks/Replaces: base-files (<< 11ubuntu5.2)
Bionic:
ubuntu-server 1.417.5:
Depends: motd-news-config
base-files 10.1ubuntu2.10:
Breaks: ubuntu-server (<< 1.417.5)
rm_conffile /etc/default/motd-news 10.1ubuntu2.10~ base-files
motd-news-config 10.1ubuntu2.10:
Breaks/Replaces: base-files (<< 10.1ubuntu2.10)
Xenial:
ubuntu-server 1.361.5:
Depends: motd-news-config
base-files 9.4ubuntu4.13:
Breaks: ubuntu-server (<< 1.361.5)
rm_conffile /etc/default/motd-news 9.4ubuntu4.13~ base-files
motd-news-config 9.4ubuntu4.13:
Breaks/Replaces: base-files (<< 9.4ubuntu4.13)
[Other Info]
a) Testcase (i) will leave around an empty /etc/default/motd-news.wasremoved file, created by the base-files postinst. This file is removed by the motd-news-config postinst, but since that package doesn't get installed in that particular scenario, the file remains. I toyed with the idea of adding an extra check to base-file's postinst, like this:
--- a/debian/postinst.in
+++ b/debian/postinst.in
@@ -133,7 +133,11 @@ motd_news_config="/etc/default/motd-news"
if [ ! -e ${motd_news_config} ]; then
if [ ! -e ${motd_news_config}.dpkg-remove ]; then
if [ ! -e ${motd_news_config}.dpkg-backup ]; then
- touch ${motd_news_config}.wasremoved
+ # The .wasremoved file only matters if ubuntu-server is installed,
+ # because that's what will pull in motd-news-config
+ if dpkg -l ubuntu-server 2>/dev/null | grep -q ^i; then
+ touch ${motd_news_config}.wasremoved
+ fi
fi
fi
fi
But deemed it too risky, and not worth further potential regressions.
b) Currently the xenial cloud images, with the exception of the AWS one, do not have ubuntu-server installed. This means that this SRU will disable motd-news on them, unless ubuntu-server was manually installed for some reason. This includes LXD xenial images as well. |
|
| 2020-08-12 20:37:05 |
Andreas Hasenack |
description |
[Impact]
The motd-news script is largely useless for desktop users, as they rarely login via a text console. It makes more sense for server users.
We can use package dependencies to have the motd-news script enabled on servers, but disabled on desktops, and still handle upgrades. This is the plan:
- move /etc/default/motd-news from base-files into a new binary package (motd-news-config, produced by src:base-files)
- have ubuntu-server depend on motd-news-config
- have base-files break current ubuntu-server, so that if base-files if upgraded and ubuntu-server is installed, ubuntu-server will also be upgraded to the new version which has the depends on motd-news-config
Care must be taken to preserve a changed /etc/default/motd-news when the upgrade installs the new motd-news-config package. For example, on a server that has set ENABLED=0 in /etc/default/motd-news and upgrades to the new base-files and ubuntu-server, and gets the new motd-config-news package, ENABLED=0 must remain set.
[Test Case]
a) base-files installed, ubuntu-server installed, unmodified /e/d/motd-news
apt install base-files
- upgrades ubuntu-server
- installs motd-news-config
- /e/d/motd-news remains, motd-news remains enabled
b) base-files installed, ubuntu-server installed, modified /e/d/motd-news
apt install base-files
- upgrades ubuntu-server
- installs motd-news-config
- /e/d/motd-news remains with the original modification
c) base-files installed, ubuntu-server not installed, unmodified /e/d/motd-news
apt install base-files
- upgrades base-files
- removes /e/d/motd-news
- motd-news is disabled
d) base-files installed, ubuntu-server not installed, modified /e/d/motd-news
apt install base-files
- upgrades base-files
- /e/d/motd-news gets renamed to backup
- motd-news is disabled
e) removing motd-news-config will also remove ubuntu-server (since it's a depends, and not a recommends)
f) upgrading just ubuntu-server should pull motd-news-config in, and force-upgrade base-files
g) Removing motd-news-server leaves /e/d/motd-news around; purging motd-news-server removes the /e/d/motd-news config file
h) base-files installed, ubuntu-server installed, removed /e/d/motd-news
- apt install base-files
- upgrades base-files, upgrades ubuntu-server, installs motd-news-config
- /e/d/motd-news is installed with ENABLED=0
i) base-files installed, ubuntu-server NOT installed, removed e/d/motd-news
- apt install base-files
- base-files is upgraded
- no /e/d/motd-news is installed, motd-news remains disabled
[Regression Potential]
This update is about config file ownership transfer: /e/d/motd-news belonged to base-files, now it belongs to motd-news-config. We tried to handle two important cases here:
a) /e/d/motd-news config was changed while it belonged to base-files. For example, an user could have set ENABLED=0. We need to transfer that change to the motd-news-config package when it is installed, otherwise this SRU would jsut re-enabled motd-news. This is handled in d/motd-news-config.postinst's configure case.
b) /e/d/motd-news config file was *removed* while it belonged to base-files. In such a case, a normal upgrade of the package (base-files in this example) would not reinstate the file. Much less this upgrade here, which has an explicit rm_conffile maintscript-helper for it. But the motd-news-config package that could be installed in the transaction would place the default config file back, and the default is ENABLED=1. Thus, a system that had motd-news disabled via removing the config file would now have it re-enabled after the upgrade.
This was trickier to handle, and we do it in base-files's postinst and motd-news-config's postinst. The drawback is that in one scenario, where just base-files is upgraded and /e/d/motd-news was manually removed by the user, there will be a /e/d/motd-news.wasremoved leftover empty file (see "other info" below for details).
In general, the regression risks here are:
- have motd-news enabled again on a system where it was previously disabled. We tried to envision two ways it would have been disabled (set ENABLED=0, and remove the config file). There are probably others
- differences in dpkg and/or debhelper behavior in older ubuntu releases leading to unexpected results (should be covered by the test cases from this SRU)
- xenial in particular is trickier, because src:base-files there does NOT use debhelper, so many of the things we take for granted have to be done by hand
- have some sort of dpkg postinst or dependency error because of unpredicted scenarios. Certain assumptions are being made, like the renames that dpkg-maintscript-helper does, and that the filename /etc/default/motd-news.wasremoved that I'm touching and verifying is really mine and not something that was there already.
- the versions I'm breaking/replacing on, and using rm_conffiles on, must be exact. These are the versions today in the archive (2020-08-12):
base-files:
x: 9.4ubuntu4.12
b: 10.1ubuntu2.9
f: 11ubuntu5.1
g: 11ubuntu10
ubuntu-meta:
x: 1.361.4
b: 1.417.4
f: 1.450.1
g: 1.452
Which reflect in these relationships in the updated packages:
Groovy:
ubuntu-server 1.453:
Depends: motd-news-config
base-files 11ubuntu11:
Breaks: ubuntu-server (<< 1.453)
rm_conffile /etc/default/motd-news 11ubuntu11~ base-files
motd-news-config 11ubuntu11:
Breaks/Replaces: base-files (<< 11ubuntu11)
Focal:
ubuntu-server 1.450.2:
Depends: motd-news-config
base-files 11ubuntu5.2:
Breaks: ubuntu-server (<< 1.450.2)
rm_conffile /etc/default/motd-news 11ubuntu5.2~ base-files
motd-news-config 11ubuntu5.2:
Breaks/Replaces: base-files (<< 11ubuntu5.2)
Bionic:
ubuntu-server 1.417.5:
Depends: motd-news-config
base-files 10.1ubuntu2.10:
Breaks: ubuntu-server (<< 1.417.5)
rm_conffile /etc/default/motd-news 10.1ubuntu2.10~ base-files
motd-news-config 10.1ubuntu2.10:
Breaks/Replaces: base-files (<< 10.1ubuntu2.10)
Xenial:
ubuntu-server 1.361.5:
Depends: motd-news-config
base-files 9.4ubuntu4.13:
Breaks: ubuntu-server (<< 1.361.5)
rm_conffile /etc/default/motd-news 9.4ubuntu4.13~ base-files
motd-news-config 9.4ubuntu4.13:
Breaks/Replaces: base-files (<< 9.4ubuntu4.13)
[Other Info]
a) Testcase (i) will leave around an empty /etc/default/motd-news.wasremoved file, created by the base-files postinst. This file is removed by the motd-news-config postinst, but since that package doesn't get installed in that particular scenario, the file remains. I toyed with the idea of adding an extra check to base-file's postinst, like this:
--- a/debian/postinst.in
+++ b/debian/postinst.in
@@ -133,7 +133,11 @@ motd_news_config="/etc/default/motd-news"
if [ ! -e ${motd_news_config} ]; then
if [ ! -e ${motd_news_config}.dpkg-remove ]; then
if [ ! -e ${motd_news_config}.dpkg-backup ]; then
- touch ${motd_news_config}.wasremoved
+ # The .wasremoved file only matters if ubuntu-server is installed,
+ # because that's what will pull in motd-news-config
+ if dpkg -l ubuntu-server 2>/dev/null | grep -q ^i; then
+ touch ${motd_news_config}.wasremoved
+ fi
fi
fi
fi
But deemed it too risky, and not worth further potential regressions.
b) Currently the xenial cloud images, with the exception of the AWS one, do not have ubuntu-server installed. This means that this SRU will disable motd-news on them, unless ubuntu-server was manually installed for some reason. This includes LXD xenial images as well. |
[Impact]
The motd-news script is largely useless for desktop users, as they rarely login via a text console. It makes more sense for server users.
We can use package dependencies to have the motd-news script enabled on servers, but disabled on desktops, and still handle upgrades. This is the plan:
- move /etc/default/motd-news from base-files into a new binary package (motd-news-config, produced by src:base-files)
- have ubuntu-server depend on motd-news-config
- have base-files break current ubuntu-server, so that if base-files if upgraded and ubuntu-server is installed, ubuntu-server will also be upgraded to the new version which has the depends on motd-news-config
Care must be taken to preserve a changed /etc/default/motd-news when the upgrade installs the new motd-news-config package. For example, on a server that has set ENABLED=0 in /etc/default/motd-news and upgrades to the new base-files and ubuntu-server, and gets the new motd-config-news package, ENABLED=0 must remain set.
[Test Case]
a) base-files installed, ubuntu-server installed, unmodified /e/d/motd-news
apt install base-files
- upgrades ubuntu-server
- installs motd-news-config
- /e/d/motd-news remains, motd-news remains enabled
b) base-files installed, ubuntu-server installed, modified /e/d/motd-news
apt install base-files
- upgrades ubuntu-server
- installs motd-news-config
- /e/d/motd-news remains with the original modification
c) base-files installed, ubuntu-server not installed, unmodified /e/d/motd-news
apt install base-files
- upgrades base-files
- removes /e/d/motd-news
- motd-news is disabled
d) base-files installed, ubuntu-server not installed, modified /e/d/motd-news
apt install base-files
- upgrades base-files
- /e/d/motd-news gets renamed to backup
- motd-news is disabled
e) removing motd-news-config will also remove ubuntu-server (since it's a depends, and not a recommends)
f) upgrading just ubuntu-server should pull motd-news-config in, and force-upgrade base-files
g) Removing motd-news-server leaves /e/d/motd-news around; purging motd-news-server removes the /e/d/motd-news config file
h) base-files installed, ubuntu-server installed, removed /e/d/motd-news
- apt install base-files
- upgrades base-files, upgrades ubuntu-server, installs motd-news-config
- /e/d/motd-news is installed with ENABLED=0
i) base-files installed, ubuntu-server NOT installed, removed e/d/motd-news
- apt install base-files
- base-files is upgraded
- no /e/d/motd-news is installed, motd-news remains disabled
[Regression Potential]
This update is about config file ownership transfer: /e/d/motd-news belonged to base-files, now it belongs to motd-news-config. We tried to handle two important cases here:
a) /e/d/motd-news config was changed while it belonged to base-files. For example, an user could have set ENABLED=0. We need to transfer that change to the motd-news-config package when it is installed, otherwise this SRU would jsut re-enabled motd-news. This is handled in d/motd-news-config.postinst's configure case.
b) /e/d/motd-news config file was *removed* while it belonged to base-files. In such a case, a normal upgrade of the package (base-files in this example) would not reinstate the file. Much less this upgrade here, which has an explicit rm_conffile maintscript-helper for it. But the motd-news-config package that could be installed in the transaction would place the default config file back, and the default is ENABLED=1. Thus, a system that had motd-news disabled via removing the config file would now have it re-enabled after the upgrade.
This was trickier to handle, and we do it in base-files's postinst and motd-news-config's postinst. The drawback is that in one scenario, where just base-files is upgraded and /e/d/motd-news was manually removed by the user, there will be a /e/d/motd-news.wasremoved leftover empty file (see "other info" below for details).
In general, the regression risks here are:
- have motd-news enabled again on a system where it was previously disabled. We tried to envision two ways it would have been disabled (set ENABLED=0, and remove the config file). There are probably others
- differences in dpkg and/or debhelper behavior in older ubuntu releases leading to unexpected results (should be covered by the test cases from this SRU)
- xenial in particular is trickier, because src:base-files there does NOT use debhelper, so many of the things we take for granted have to be done by hand
- have some sort of dpkg postinst or dependency error because of unpredicted scenarios. Certain assumptions are being made, like the renames that dpkg-maintscript-helper does, and that the filename /etc/default/motd-news.wasremoved that I'm touching and verifying is really mine and not something that was there already.
- the versions I'm breaking/replacing on, and using rm_conffiles on, must be exact. These are the versions today in the archive (2020-08-12):
base-files:
x: 9.4ubuntu4.12
b: 10.1ubuntu2.9
f: 11ubuntu5.1
g: 11ubuntu10
ubuntu-meta:
x: 1.361.4
b: 1.417.4
f: 1.450.1
g: 1.452
Which reflect in these relationships in the updated packages:
Groovy:
ubuntu-server 1.453:
Depends: motd-news-config
base-files 11ubuntu11:
Breaks: ubuntu-server (<< 1.453)
rm_conffile /etc/default/motd-news 11ubuntu11~ base-files
motd-news-config 11ubuntu11:
Breaks/Replaces: base-files (<< 11ubuntu11)
Focal:
ubuntu-server 1.450.2:
Depends: motd-news-config
base-files 11ubuntu5.2:
Breaks: ubuntu-server (<< 1.450.2)
rm_conffile /etc/default/motd-news 11ubuntu5.2~ base-files
motd-news-config 11ubuntu5.2:
Breaks/Replaces: base-files (<< 11ubuntu5.2)
Bionic:
ubuntu-server 1.417.5:
Depends: motd-news-config
base-files 10.1ubuntu2.10:
Breaks: ubuntu-server (<< 1.417.5)
rm_conffile /etc/default/motd-news 10.1ubuntu2.10~ base-files
motd-news-config 10.1ubuntu2.10:
Breaks/Replaces: base-files (<< 10.1ubuntu2.10)
Xenial:
ubuntu-server 1.361.5:
Depends: motd-news-config
base-files 9.4ubuntu4.13:
Breaks: ubuntu-server (<< 1.361.5)
rm_conffile /etc/default/motd-news 9.4ubuntu4.13~ base-files
motd-news-config 9.4ubuntu4.13:
Breaks/Replaces: base-files (<< 9.4ubuntu4.13)
[Other Info]
a) Testcase (i) will leave around an empty /etc/default/motd-news.wasremoved file, created by the base-files postinst. This file is removed by the motd-news-config postinst, but since that package doesn't get installed in that particular scenario, the file remains. I toyed with the idea of adding an extra check to base-file's postinst, like this:
--- a/debian/postinst.in
+++ b/debian/postinst.in
@@ -133,7 +133,11 @@ motd_news_config="/etc/default/motd-news"
if [ ! -e ${motd_news_config} ]; then
if [ ! -e ${motd_news_config}.dpkg-remove ]; then
if [ ! -e ${motd_news_config}.dpkg-backup ]; then
- touch ${motd_news_config}.wasremoved
+ # The .wasremoved file only matters if ubuntu-server is installed,
+ # because that's what will pull in motd-news-config
+ if dpkg -l ubuntu-server 2>/dev/null | grep -q ^i; then
+ touch ${motd_news_config}.wasremoved
+ fi
fi
fi
fi
But deemed it too risky, and not worth further potential regressions. It seemed to work, though, at least for groovy.
b) Currently the xenial cloud images, with the exception of the AWS one, do not have ubuntu-server installed. This means that this SRU will disable motd-news on them, unless ubuntu-server was manually installed for some reason. This includes LXD xenial images as well. |
|
| 2020-08-13 20:46:22 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/base-files/+git/base-files/+merge/389300 |
|
| 2020-08-14 00:46:29 |
Launchpad Janitor |
base-files (Ubuntu Groovy): status |
In Progress |
Fix Released |
|
| 2020-08-14 17:34:13 |
Launchpad Janitor |
merge proposal unlinked |
https://code.launchpad.net/~ahasenack/ubuntu/+source/base-files/+git/base-files/+merge/389300 |
|
|
| 2020-08-14 18:19:42 |
Andreas Hasenack |
description |
[Impact]
The motd-news script is largely useless for desktop users, as they rarely login via a text console. It makes more sense for server users.
We can use package dependencies to have the motd-news script enabled on servers, but disabled on desktops, and still handle upgrades. This is the plan:
- move /etc/default/motd-news from base-files into a new binary package (motd-news-config, produced by src:base-files)
- have ubuntu-server depend on motd-news-config
- have base-files break current ubuntu-server, so that if base-files if upgraded and ubuntu-server is installed, ubuntu-server will also be upgraded to the new version which has the depends on motd-news-config
Care must be taken to preserve a changed /etc/default/motd-news when the upgrade installs the new motd-news-config package. For example, on a server that has set ENABLED=0 in /etc/default/motd-news and upgrades to the new base-files and ubuntu-server, and gets the new motd-config-news package, ENABLED=0 must remain set.
[Test Case]
a) base-files installed, ubuntu-server installed, unmodified /e/d/motd-news
apt install base-files
- upgrades ubuntu-server
- installs motd-news-config
- /e/d/motd-news remains, motd-news remains enabled
b) base-files installed, ubuntu-server installed, modified /e/d/motd-news
apt install base-files
- upgrades ubuntu-server
- installs motd-news-config
- /e/d/motd-news remains with the original modification
c) base-files installed, ubuntu-server not installed, unmodified /e/d/motd-news
apt install base-files
- upgrades base-files
- removes /e/d/motd-news
- motd-news is disabled
d) base-files installed, ubuntu-server not installed, modified /e/d/motd-news
apt install base-files
- upgrades base-files
- /e/d/motd-news gets renamed to backup
- motd-news is disabled
e) removing motd-news-config will also remove ubuntu-server (since it's a depends, and not a recommends)
f) upgrading just ubuntu-server should pull motd-news-config in, and force-upgrade base-files
g) Removing motd-news-server leaves /e/d/motd-news around; purging motd-news-server removes the /e/d/motd-news config file
h) base-files installed, ubuntu-server installed, removed /e/d/motd-news
- apt install base-files
- upgrades base-files, upgrades ubuntu-server, installs motd-news-config
- /e/d/motd-news is installed with ENABLED=0
i) base-files installed, ubuntu-server NOT installed, removed e/d/motd-news
- apt install base-files
- base-files is upgraded
- no /e/d/motd-news is installed, motd-news remains disabled
[Regression Potential]
This update is about config file ownership transfer: /e/d/motd-news belonged to base-files, now it belongs to motd-news-config. We tried to handle two important cases here:
a) /e/d/motd-news config was changed while it belonged to base-files. For example, an user could have set ENABLED=0. We need to transfer that change to the motd-news-config package when it is installed, otherwise this SRU would jsut re-enabled motd-news. This is handled in d/motd-news-config.postinst's configure case.
b) /e/d/motd-news config file was *removed* while it belonged to base-files. In such a case, a normal upgrade of the package (base-files in this example) would not reinstate the file. Much less this upgrade here, which has an explicit rm_conffile maintscript-helper for it. But the motd-news-config package that could be installed in the transaction would place the default config file back, and the default is ENABLED=1. Thus, a system that had motd-news disabled via removing the config file would now have it re-enabled after the upgrade.
This was trickier to handle, and we do it in base-files's postinst and motd-news-config's postinst. The drawback is that in one scenario, where just base-files is upgraded and /e/d/motd-news was manually removed by the user, there will be a /e/d/motd-news.wasremoved leftover empty file (see "other info" below for details).
In general, the regression risks here are:
- have motd-news enabled again on a system where it was previously disabled. We tried to envision two ways it would have been disabled (set ENABLED=0, and remove the config file). There are probably others
- differences in dpkg and/or debhelper behavior in older ubuntu releases leading to unexpected results (should be covered by the test cases from this SRU)
- xenial in particular is trickier, because src:base-files there does NOT use debhelper, so many of the things we take for granted have to be done by hand
- have some sort of dpkg postinst or dependency error because of unpredicted scenarios. Certain assumptions are being made, like the renames that dpkg-maintscript-helper does, and that the filename /etc/default/motd-news.wasremoved that I'm touching and verifying is really mine and not something that was there already.
- the versions I'm breaking/replacing on, and using rm_conffiles on, must be exact. These are the versions today in the archive (2020-08-12):
base-files:
x: 9.4ubuntu4.12
b: 10.1ubuntu2.9
f: 11ubuntu5.1
g: 11ubuntu10
ubuntu-meta:
x: 1.361.4
b: 1.417.4
f: 1.450.1
g: 1.452
Which reflect in these relationships in the updated packages:
Groovy:
ubuntu-server 1.453:
Depends: motd-news-config
base-files 11ubuntu11:
Breaks: ubuntu-server (<< 1.453)
rm_conffile /etc/default/motd-news 11ubuntu11~ base-files
motd-news-config 11ubuntu11:
Breaks/Replaces: base-files (<< 11ubuntu11)
Focal:
ubuntu-server 1.450.2:
Depends: motd-news-config
base-files 11ubuntu5.2:
Breaks: ubuntu-server (<< 1.450.2)
rm_conffile /etc/default/motd-news 11ubuntu5.2~ base-files
motd-news-config 11ubuntu5.2:
Breaks/Replaces: base-files (<< 11ubuntu5.2)
Bionic:
ubuntu-server 1.417.5:
Depends: motd-news-config
base-files 10.1ubuntu2.10:
Breaks: ubuntu-server (<< 1.417.5)
rm_conffile /etc/default/motd-news 10.1ubuntu2.10~ base-files
motd-news-config 10.1ubuntu2.10:
Breaks/Replaces: base-files (<< 10.1ubuntu2.10)
Xenial:
ubuntu-server 1.361.5:
Depends: motd-news-config
base-files 9.4ubuntu4.13:
Breaks: ubuntu-server (<< 1.361.5)
rm_conffile /etc/default/motd-news 9.4ubuntu4.13~ base-files
motd-news-config 9.4ubuntu4.13:
Breaks/Replaces: base-files (<< 9.4ubuntu4.13)
[Other Info]
a) Testcase (i) will leave around an empty /etc/default/motd-news.wasremoved file, created by the base-files postinst. This file is removed by the motd-news-config postinst, but since that package doesn't get installed in that particular scenario, the file remains. I toyed with the idea of adding an extra check to base-file's postinst, like this:
--- a/debian/postinst.in
+++ b/debian/postinst.in
@@ -133,7 +133,11 @@ motd_news_config="/etc/default/motd-news"
if [ ! -e ${motd_news_config} ]; then
if [ ! -e ${motd_news_config}.dpkg-remove ]; then
if [ ! -e ${motd_news_config}.dpkg-backup ]; then
- touch ${motd_news_config}.wasremoved
+ # The .wasremoved file only matters if ubuntu-server is installed,
+ # because that's what will pull in motd-news-config
+ if dpkg -l ubuntu-server 2>/dev/null | grep -q ^i; then
+ touch ${motd_news_config}.wasremoved
+ fi
fi
fi
fi
But deemed it too risky, and not worth further potential regressions. It seemed to work, though, at least for groovy.
b) Currently the xenial cloud images, with the exception of the AWS one, do not have ubuntu-server installed. This means that this SRU will disable motd-news on them, unless ubuntu-server was manually installed for some reason. This includes LXD xenial images as well. |
[Impact]
The motd-news script is largely useless for desktop users, as they rarely login via a text console. It makes more sense for server users.
We can use package dependencies to have the motd-news script enabled on servers, but disabled on desktops, and still handle upgrades. This is the plan:
- move /etc/default/motd-news from base-files into a new binary package (motd-news-config, produced by src:base-files)
- have ubuntu-server depend on motd-news-config
- have base-files break current ubuntu-server, so that if base-files if upgraded and ubuntu-server is installed, ubuntu-server will also be upgraded to the new version which has the depends on motd-news-config
Care must be taken to preserve a changed /etc/default/motd-news when the upgrade installs the new motd-news-config package. For example, on a server that has set ENABLED=0 in /etc/default/motd-news and upgrades to the new base-files and ubuntu-server, and gets the new motd-config-news package, ENABLED=0 must remain set.
[Test Case]
a) base-files installed, ubuntu-server installed, unmodified /e/d/motd-news
apt install base-files
- upgrades ubuntu-server
- installs motd-news-config
- /e/d/motd-news remains, motd-news remains enabled
b) base-files installed, ubuntu-server installed, modified /e/d/motd-news
apt install base-files
- upgrades ubuntu-server
- installs motd-news-config
- /e/d/motd-news remains with the original modification
c) base-files installed, ubuntu-server not installed, unmodified /e/d/motd-news
apt install base-files
- upgrades base-files
- removes /e/d/motd-news
- motd-news is disabled
d) base-files installed, ubuntu-server not installed, modified /e/d/motd-news
apt install base-files
- upgrades base-files
- /e/d/motd-news gets renamed to backup
- motd-news is disabled
e) removing motd-news-config will also remove ubuntu-server (since it's a depends, and not a recommends)
f) upgrading just ubuntu-server should pull motd-news-config in, and force-upgrade base-files
g) Removing motd-news-server leaves /e/d/motd-news around; purging motd-news-server removes the /e/d/motd-news config file
h) base-files installed, ubuntu-server installed, removed /e/d/motd-news
- apt install base-files
- upgrades base-files, upgrades ubuntu-server, installs motd-news-config
- /e/d/motd-news is installed with ENABLED=0
i) base-files installed, ubuntu-server NOT installed, removed e/d/motd-news
- apt install base-files
- base-files is upgraded
- no /e/d/motd-news is installed, motd-news remains disabled
[Regression Potential]
This update is about config file ownership transfer: /e/d/motd-news belonged to base-files, now it belongs to motd-news-config. We tried to handle two important cases here:
a) /e/d/motd-news config was changed while it belonged to base-files. For example, an user could have set ENABLED=0. We need to transfer that change to the motd-news-config package when it is installed, otherwise this SRU would jsut re-enabled motd-news. This is handled in d/motd-news-config.postinst's configure case.
b) /e/d/motd-news config file was *removed* while it belonged to base-files. In such a case, a normal upgrade of the package (base-files in this example) would not reinstate the file. Much less this upgrade here, which has an explicit rm_conffile maintscript-helper for it. But the motd-news-config package that could be installed in the transaction would place the default config file back, and the default is ENABLED=1. Thus, a system that had motd-news disabled via removing the config file would now have it re-enabled after the upgrade.
This was trickier to handle, and we do it in base-files's postinst and motd-news-config's postinst. The drawback is that in one scenario, where just base-files is upgraded and /e/d/motd-news was manually removed by the user, there will be a /e/d/motd-news.wasremoved leftover empty file (see "other info" below for details).
In general, the regression risks here are:
- have motd-news enabled again on a system where it was previously disabled. We tried to envision two ways it would have been disabled (set ENABLED=0, and remove the config file). There are probably others
- differences in dpkg and/or debhelper behavior in older ubuntu releases leading to unexpected results (should be covered by the test cases from this SRU)
- xenial in particular is trickier, because src:base-files there does NOT use debhelper, so many of the things we take for granted have to be done by hand
- have some sort of dpkg postinst or dependency error because of unpredicted scenarios. Certain assumptions are being made, like the renames that dpkg-maintscript-helper does, and that the filename /etc/default/motd-news.wasremoved that I'm touching and verifying is really mine and not something that was there already.
- the versions I'm breaking/replacing on, and using rm_conffiles on, must be exact. These are the versions today in the archive (2020-08-12):
base-files:
x: 9.4ubuntu4.12
b: 10.1ubuntu2.9
f: 11ubuntu5.1
g: 11ubuntu12 (was 11ubuntu10)
ubuntu-meta:
x: 1.361.4
b: 1.417.4
f: 1.450.1
g: 1.452
Which reflect in these relationships in the updated packages:
Groovy:
ubuntu-server 1.453:
Depends: motd-news-config
base-files 11ubuntu11:
Breaks: ubuntu-server (<< 1.453)
rm_conffile /etc/default/motd-news 11ubuntu11~ base-files
motd-news-config 11ubuntu11:
Breaks/Replaces: base-files (<< 11ubuntu11)
Focal:
ubuntu-server 1.450.2:
Depends: motd-news-config
base-files 11ubuntu5.2:
Breaks: ubuntu-server (<< 1.450.2)
rm_conffile /etc/default/motd-news 11ubuntu5.2~ base-files
motd-news-config 11ubuntu5.2:
Breaks/Replaces: base-files (<< 11ubuntu5.2)
Bionic:
ubuntu-server 1.417.5:
Depends: motd-news-config
base-files 10.1ubuntu2.10:
Breaks: ubuntu-server (<< 1.417.5)
rm_conffile /etc/default/motd-news 10.1ubuntu2.10~ base-files
motd-news-config 10.1ubuntu2.10:
Breaks/Replaces: base-files (<< 10.1ubuntu2.10)
Xenial:
ubuntu-server 1.361.5:
Depends: motd-news-config
base-files 9.4ubuntu4.13:
Breaks: ubuntu-server (<< 1.361.5)
rm_conffile /etc/default/motd-news 9.4ubuntu4.13~ base-files
motd-news-config 9.4ubuntu4.13:
Breaks/Replaces: base-files (<< 9.4ubuntu4.13)
[Other Info]
a) Testcase (i) will leave around an empty /etc/default/motd-news.wasremoved file, created by the base-files postinst. This file is removed by the motd-news-config postinst, but since that package doesn't get installed in that particular scenario, the file remains. I toyed with the idea of adding an extra check to base-file's postinst, like this:
--- a/debian/postinst.in
+++ b/debian/postinst.in
@@ -133,7 +133,11 @@ motd_news_config="/etc/default/motd-news"
if [ ! -e ${motd_news_config} ]; then
if [ ! -e ${motd_news_config}.dpkg-remove ]; then
if [ ! -e ${motd_news_config}.dpkg-backup ]; then
- touch ${motd_news_config}.wasremoved
+ # The .wasremoved file only matters if ubuntu-server is installed,
+ # because that's what will pull in motd-news-config
+ if dpkg -l ubuntu-server 2>/dev/null | grep -q ^i; then
+ touch ${motd_news_config}.wasremoved
+ fi
fi
fi
fi
But deemed it too risky, and not worth further potential regressions. It seemed to work, though, at least for groovy.
b) Currently the xenial cloud images, with the exception of the AWS one, do not have ubuntu-server installed. This means that this SRU will disable motd-news on them, unless ubuntu-server was manually installed for some reason. This includes LXD xenial images as well. |
|
| 2020-08-14 18:29:04 |
Andreas Hasenack |
description |
[Impact]
The motd-news script is largely useless for desktop users, as they rarely login via a text console. It makes more sense for server users.
We can use package dependencies to have the motd-news script enabled on servers, but disabled on desktops, and still handle upgrades. This is the plan:
- move /etc/default/motd-news from base-files into a new binary package (motd-news-config, produced by src:base-files)
- have ubuntu-server depend on motd-news-config
- have base-files break current ubuntu-server, so that if base-files if upgraded and ubuntu-server is installed, ubuntu-server will also be upgraded to the new version which has the depends on motd-news-config
Care must be taken to preserve a changed /etc/default/motd-news when the upgrade installs the new motd-news-config package. For example, on a server that has set ENABLED=0 in /etc/default/motd-news and upgrades to the new base-files and ubuntu-server, and gets the new motd-config-news package, ENABLED=0 must remain set.
[Test Case]
a) base-files installed, ubuntu-server installed, unmodified /e/d/motd-news
apt install base-files
- upgrades ubuntu-server
- installs motd-news-config
- /e/d/motd-news remains, motd-news remains enabled
b) base-files installed, ubuntu-server installed, modified /e/d/motd-news
apt install base-files
- upgrades ubuntu-server
- installs motd-news-config
- /e/d/motd-news remains with the original modification
c) base-files installed, ubuntu-server not installed, unmodified /e/d/motd-news
apt install base-files
- upgrades base-files
- removes /e/d/motd-news
- motd-news is disabled
d) base-files installed, ubuntu-server not installed, modified /e/d/motd-news
apt install base-files
- upgrades base-files
- /e/d/motd-news gets renamed to backup
- motd-news is disabled
e) removing motd-news-config will also remove ubuntu-server (since it's a depends, and not a recommends)
f) upgrading just ubuntu-server should pull motd-news-config in, and force-upgrade base-files
g) Removing motd-news-server leaves /e/d/motd-news around; purging motd-news-server removes the /e/d/motd-news config file
h) base-files installed, ubuntu-server installed, removed /e/d/motd-news
- apt install base-files
- upgrades base-files, upgrades ubuntu-server, installs motd-news-config
- /e/d/motd-news is installed with ENABLED=0
i) base-files installed, ubuntu-server NOT installed, removed e/d/motd-news
- apt install base-files
- base-files is upgraded
- no /e/d/motd-news is installed, motd-news remains disabled
[Regression Potential]
This update is about config file ownership transfer: /e/d/motd-news belonged to base-files, now it belongs to motd-news-config. We tried to handle two important cases here:
a) /e/d/motd-news config was changed while it belonged to base-files. For example, an user could have set ENABLED=0. We need to transfer that change to the motd-news-config package when it is installed, otherwise this SRU would jsut re-enabled motd-news. This is handled in d/motd-news-config.postinst's configure case.
b) /e/d/motd-news config file was *removed* while it belonged to base-files. In such a case, a normal upgrade of the package (base-files in this example) would not reinstate the file. Much less this upgrade here, which has an explicit rm_conffile maintscript-helper for it. But the motd-news-config package that could be installed in the transaction would place the default config file back, and the default is ENABLED=1. Thus, a system that had motd-news disabled via removing the config file would now have it re-enabled after the upgrade.
This was trickier to handle, and we do it in base-files's postinst and motd-news-config's postinst. The drawback is that in one scenario, where just base-files is upgraded and /e/d/motd-news was manually removed by the user, there will be a /e/d/motd-news.wasremoved leftover empty file (see "other info" below for details).
In general, the regression risks here are:
- have motd-news enabled again on a system where it was previously disabled. We tried to envision two ways it would have been disabled (set ENABLED=0, and remove the config file). There are probably others
- differences in dpkg and/or debhelper behavior in older ubuntu releases leading to unexpected results (should be covered by the test cases from this SRU)
- xenial in particular is trickier, because src:base-files there does NOT use debhelper, so many of the things we take for granted have to be done by hand
- have some sort of dpkg postinst or dependency error because of unpredicted scenarios. Certain assumptions are being made, like the renames that dpkg-maintscript-helper does, and that the filename /etc/default/motd-news.wasremoved that I'm touching and verifying is really mine and not something that was there already.
- the versions I'm breaking/replacing on, and using rm_conffiles on, must be exact. These are the versions today in the archive (2020-08-12):
base-files:
x: 9.4ubuntu4.12
b: 10.1ubuntu2.9
f: 11ubuntu5.1
g: 11ubuntu12 (was 11ubuntu10)
ubuntu-meta:
x: 1.361.4
b: 1.417.4
f: 1.450.1
g: 1.452
Which reflect in these relationships in the updated packages:
Groovy:
ubuntu-server 1.453:
Depends: motd-news-config
base-files 11ubuntu11:
Breaks: ubuntu-server (<< 1.453)
rm_conffile /etc/default/motd-news 11ubuntu11~ base-files
motd-news-config 11ubuntu11:
Breaks/Replaces: base-files (<< 11ubuntu11)
Focal:
ubuntu-server 1.450.2:
Depends: motd-news-config
base-files 11ubuntu5.2:
Breaks: ubuntu-server (<< 1.450.2)
rm_conffile /etc/default/motd-news 11ubuntu5.2~ base-files
motd-news-config 11ubuntu5.2:
Breaks/Replaces: base-files (<< 11ubuntu5.2)
Bionic:
ubuntu-server 1.417.5:
Depends: motd-news-config
base-files 10.1ubuntu2.10:
Breaks: ubuntu-server (<< 1.417.5)
rm_conffile /etc/default/motd-news 10.1ubuntu2.10~ base-files
motd-news-config 10.1ubuntu2.10:
Breaks/Replaces: base-files (<< 10.1ubuntu2.10)
Xenial:
ubuntu-server 1.361.5:
Depends: motd-news-config
base-files 9.4ubuntu4.13:
Breaks: ubuntu-server (<< 1.361.5)
rm_conffile /etc/default/motd-news 9.4ubuntu4.13~ base-files
motd-news-config 9.4ubuntu4.13:
Breaks/Replaces: base-files (<< 9.4ubuntu4.13)
[Other Info]
a) Testcase (i) will leave around an empty /etc/default/motd-news.wasremoved file, created by the base-files postinst. This file is removed by the motd-news-config postinst, but since that package doesn't get installed in that particular scenario, the file remains. I toyed with the idea of adding an extra check to base-file's postinst, like this:
--- a/debian/postinst.in
+++ b/debian/postinst.in
@@ -133,7 +133,11 @@ motd_news_config="/etc/default/motd-news"
if [ ! -e ${motd_news_config} ]; then
if [ ! -e ${motd_news_config}.dpkg-remove ]; then
if [ ! -e ${motd_news_config}.dpkg-backup ]; then
- touch ${motd_news_config}.wasremoved
+ # The .wasremoved file only matters if ubuntu-server is installed,
+ # because that's what will pull in motd-news-config
+ if dpkg -l ubuntu-server 2>/dev/null | grep -q ^i; then
+ touch ${motd_news_config}.wasremoved
+ fi
fi
fi
fi
But deemed it too risky, and not worth further potential regressions. It seemed to work, though, at least for groovy.
b) Currently the xenial cloud images, with the exception of the AWS one, do not have ubuntu-server installed. This means that this SRU will disable motd-news on them, unless ubuntu-server was manually installed for some reason. This includes LXD xenial images as well. |
[Impact]
The motd-news script is largely useless for desktop users, as they rarely login via a text console. It makes more sense for server users.
We can use package dependencies to have the motd-news script enabled on servers, but disabled on desktops, and still handle upgrades. This is the plan:
- move /etc/default/motd-news from base-files into a new binary package (motd-news-config, produced by src:base-files)
- have ubuntu-server depend on motd-news-config
- have base-files break current ubuntu-server, so that if base-files if upgraded and ubuntu-server is installed, ubuntu-server will also be upgraded to the new version which has the depends on motd-news-config
Care must be taken to preserve a changed /etc/default/motd-news when the upgrade installs the new motd-news-config package. For example, on a server that has set ENABLED=0 in /etc/default/motd-news and upgrades to the new base-files and ubuntu-server, and gets the new motd-config-news package, ENABLED=0 must remain set.
[Test Case]
a) base-files installed, ubuntu-server installed, unmodified /e/d/motd-news
apt install base-files
- upgrades ubuntu-server
- installs motd-news-config
- /e/d/motd-news remains, motd-news remains enabled
b) base-files installed, ubuntu-server installed, modified /e/d/motd-news
apt install base-files
- upgrades ubuntu-server
- installs motd-news-config
- /e/d/motd-news remains with the original modification
c) base-files installed, ubuntu-server not installed, unmodified /e/d/motd-news
apt install base-files
- upgrades base-files
- removes /e/d/motd-news
- motd-news is disabled
d) base-files installed, ubuntu-server not installed, modified /e/d/motd-news
apt install base-files
- upgrades base-files
- /e/d/motd-news gets renamed to backup
- motd-news is disabled
e) removing motd-news-config will also remove ubuntu-server (since it's a depends, and not a recommends)
f) upgrading just ubuntu-server should pull motd-news-config in, and force-upgrade base-files
g) Removing motd-news-server leaves /e/d/motd-news around; purging motd-news-server removes the /e/d/motd-news config file
h) base-files installed, ubuntu-server installed, removed /e/d/motd-news
- apt install base-files
- upgrades base-files, upgrades ubuntu-server, installs motd-news-config
- /e/d/motd-news is installed with ENABLED=0
i) base-files installed, ubuntu-server NOT installed, removed e/d/motd-news
- apt install base-files
- base-files is upgraded
- no /e/d/motd-news is installed, motd-news remains disabled
j) Perform a release upgrade from the previous ubuntu release to the one being tested while having ubuntu-server NOT installed (or use a desktop install).
[Regression Potential]
This update is about config file ownership transfer: /e/d/motd-news belonged to base-files, now it belongs to motd-news-config. We tried to handle two important cases here:
a) /e/d/motd-news config was changed while it belonged to base-files. For example, an user could have set ENABLED=0. We need to transfer that change to the motd-news-config package when it is installed, otherwise this SRU would jsut re-enabled motd-news. This is handled in d/motd-news-config.postinst's configure case.
b) /e/d/motd-news config file was *removed* while it belonged to base-files. In such a case, a normal upgrade of the package (base-files in this example) would not reinstate the file. Much less this upgrade here, which has an explicit rm_conffile maintscript-helper for it. But the motd-news-config package that could be installed in the transaction would place the default config file back, and the default is ENABLED=1. Thus, a system that had motd-news disabled via removing the config file would now have it re-enabled after the upgrade.
This was trickier to handle, and we do it in base-files's postinst and motd-news-config's postinst. The drawback is that in one scenario, where just base-files is upgraded and /e/d/motd-news was manually removed by the user, there will be a /e/d/motd-news.wasremoved leftover empty file (see "other info" below for details).
In general, the regression risks here are:
- have motd-news enabled again on a system where it was previously disabled. We tried to envision two ways it would have been disabled (set ENABLED=0, and remove the config file). There are probably others
- differences in dpkg and/or debhelper behavior in older ubuntu releases leading to unexpected results (should be covered by the test cases from this SRU)
- xenial in particular is trickier, because src:base-files there does NOT use debhelper, so many of the things we take for granted have to be done by hand
- have some sort of dpkg postinst or dependency error because of unpredicted scenarios. Certain assumptions are being made, like the renames that dpkg-maintscript-helper does, and that the filename /etc/default/motd-news.wasremoved that I'm touching and verifying is really mine and not something that was there already.
- the versions I'm breaking/replacing on, and using rm_conffiles on, must be exact. These are the versions today in the archive (2020-08-12):
base-files:
x: 9.4ubuntu4.12
b: 10.1ubuntu2.9
f: 11ubuntu5.1
g: 11ubuntu12 (was 11ubuntu10)
ubuntu-meta:
x: 1.361.4
b: 1.417.4
f: 1.450.1
g: 1.452
Which reflect in these relationships in the updated packages:
Groovy:
ubuntu-server 1.453:
Depends: motd-news-config
base-files 11ubuntu11:
Breaks: ubuntu-server (<< 1.453)
rm_conffile /etc/default/motd-news 11ubuntu11~ base-files
motd-news-config 11ubuntu11:
Breaks/Replaces: base-files (<< 11ubuntu11)
Focal:
ubuntu-server 1.450.2:
Depends: motd-news-config
base-files 11ubuntu5.2:
Breaks: ubuntu-server (<< 1.450.2)
rm_conffile /etc/default/motd-news 11ubuntu5.2~ base-files
motd-news-config 11ubuntu5.2:
Breaks/Replaces: base-files (<< 11ubuntu5.2)
Bionic:
ubuntu-server 1.417.5:
Depends: motd-news-config
base-files 10.1ubuntu2.10:
Breaks: ubuntu-server (<< 1.417.5)
rm_conffile /etc/default/motd-news 10.1ubuntu2.10~ base-files
motd-news-config 10.1ubuntu2.10:
Breaks/Replaces: base-files (<< 10.1ubuntu2.10)
Xenial:
ubuntu-server 1.361.5:
Depends: motd-news-config
base-files 9.4ubuntu4.13:
Breaks: ubuntu-server (<< 1.361.5)
rm_conffile /etc/default/motd-news 9.4ubuntu4.13~ base-files
motd-news-config 9.4ubuntu4.13:
Breaks/Replaces: base-files (<< 9.4ubuntu4.13)
[Other Info]
a) Testcase (i) will leave around an empty /etc/default/motd-news.wasremoved file, created by the base-files postinst. This file is removed by the motd-news-config postinst, but since that package doesn't get installed in that particular scenario, the file remains. I toyed with the idea of adding an extra check to base-file's postinst, like this:
--- a/debian/postinst.in
+++ b/debian/postinst.in
@@ -133,7 +133,11 @@ motd_news_config="/etc/default/motd-news"
if [ ! -e ${motd_news_config} ]; then
if [ ! -e ${motd_news_config}.dpkg-remove ]; then
if [ ! -e ${motd_news_config}.dpkg-backup ]; then
- touch ${motd_news_config}.wasremoved
+ # The .wasremoved file only matters if ubuntu-server is installed,
+ # because that's what will pull in motd-news-config
+ if dpkg -l ubuntu-server 2>/dev/null | grep -q ^i; then
+ touch ${motd_news_config}.wasremoved
+ fi
fi
fi
fi
But deemed it too risky, and not worth further potential regressions. It seemed to work, though, at least for groovy.
b) Currently the xenial cloud images, with the exception of the AWS one, do not have ubuntu-server installed. This means that this SRU will disable motd-news on them, unless ubuntu-server was manually installed for some reason. This includes LXD xenial images as well.
c) The new motd-news-config package has its d/control priority set to "optional", so a release upgrade won't pick it up (presumably the same applies to the installer). I've been told there are archive overrides that might need updating as well: dear SRU team member, please check, or ask an archive admin to check. |
|
| 2020-08-14 18:33:17 |
Andreas Hasenack |
description |
[Impact]
The motd-news script is largely useless for desktop users, as they rarely login via a text console. It makes more sense for server users.
We can use package dependencies to have the motd-news script enabled on servers, but disabled on desktops, and still handle upgrades. This is the plan:
- move /etc/default/motd-news from base-files into a new binary package (motd-news-config, produced by src:base-files)
- have ubuntu-server depend on motd-news-config
- have base-files break current ubuntu-server, so that if base-files if upgraded and ubuntu-server is installed, ubuntu-server will also be upgraded to the new version which has the depends on motd-news-config
Care must be taken to preserve a changed /etc/default/motd-news when the upgrade installs the new motd-news-config package. For example, on a server that has set ENABLED=0 in /etc/default/motd-news and upgrades to the new base-files and ubuntu-server, and gets the new motd-config-news package, ENABLED=0 must remain set.
[Test Case]
a) base-files installed, ubuntu-server installed, unmodified /e/d/motd-news
apt install base-files
- upgrades ubuntu-server
- installs motd-news-config
- /e/d/motd-news remains, motd-news remains enabled
b) base-files installed, ubuntu-server installed, modified /e/d/motd-news
apt install base-files
- upgrades ubuntu-server
- installs motd-news-config
- /e/d/motd-news remains with the original modification
c) base-files installed, ubuntu-server not installed, unmodified /e/d/motd-news
apt install base-files
- upgrades base-files
- removes /e/d/motd-news
- motd-news is disabled
d) base-files installed, ubuntu-server not installed, modified /e/d/motd-news
apt install base-files
- upgrades base-files
- /e/d/motd-news gets renamed to backup
- motd-news is disabled
e) removing motd-news-config will also remove ubuntu-server (since it's a depends, and not a recommends)
f) upgrading just ubuntu-server should pull motd-news-config in, and force-upgrade base-files
g) Removing motd-news-server leaves /e/d/motd-news around; purging motd-news-server removes the /e/d/motd-news config file
h) base-files installed, ubuntu-server installed, removed /e/d/motd-news
- apt install base-files
- upgrades base-files, upgrades ubuntu-server, installs motd-news-config
- /e/d/motd-news is installed with ENABLED=0
i) base-files installed, ubuntu-server NOT installed, removed e/d/motd-news
- apt install base-files
- base-files is upgraded
- no /e/d/motd-news is installed, motd-news remains disabled
j) Perform a release upgrade from the previous ubuntu release to the one being tested while having ubuntu-server NOT installed (or use a desktop install).
[Regression Potential]
This update is about config file ownership transfer: /e/d/motd-news belonged to base-files, now it belongs to motd-news-config. We tried to handle two important cases here:
a) /e/d/motd-news config was changed while it belonged to base-files. For example, an user could have set ENABLED=0. We need to transfer that change to the motd-news-config package when it is installed, otherwise this SRU would jsut re-enabled motd-news. This is handled in d/motd-news-config.postinst's configure case.
b) /e/d/motd-news config file was *removed* while it belonged to base-files. In such a case, a normal upgrade of the package (base-files in this example) would not reinstate the file. Much less this upgrade here, which has an explicit rm_conffile maintscript-helper for it. But the motd-news-config package that could be installed in the transaction would place the default config file back, and the default is ENABLED=1. Thus, a system that had motd-news disabled via removing the config file would now have it re-enabled after the upgrade.
This was trickier to handle, and we do it in base-files's postinst and motd-news-config's postinst. The drawback is that in one scenario, where just base-files is upgraded and /e/d/motd-news was manually removed by the user, there will be a /e/d/motd-news.wasremoved leftover empty file (see "other info" below for details).
In general, the regression risks here are:
- have motd-news enabled again on a system where it was previously disabled. We tried to envision two ways it would have been disabled (set ENABLED=0, and remove the config file). There are probably others
- differences in dpkg and/or debhelper behavior in older ubuntu releases leading to unexpected results (should be covered by the test cases from this SRU)
- xenial in particular is trickier, because src:base-files there does NOT use debhelper, so many of the things we take for granted have to be done by hand
- have some sort of dpkg postinst or dependency error because of unpredicted scenarios. Certain assumptions are being made, like the renames that dpkg-maintscript-helper does, and that the filename /etc/default/motd-news.wasremoved that I'm touching and verifying is really mine and not something that was there already.
- the versions I'm breaking/replacing on, and using rm_conffiles on, must be exact. These are the versions today in the archive (2020-08-12):
base-files:
x: 9.4ubuntu4.12
b: 10.1ubuntu2.9
f: 11ubuntu5.1
g: 11ubuntu12 (was 11ubuntu10)
ubuntu-meta:
x: 1.361.4
b: 1.417.4
f: 1.450.1
g: 1.452
Which reflect in these relationships in the updated packages:
Groovy:
ubuntu-server 1.453:
Depends: motd-news-config
base-files 11ubuntu11:
Breaks: ubuntu-server (<< 1.453)
rm_conffile /etc/default/motd-news 11ubuntu11~ base-files
motd-news-config 11ubuntu11:
Breaks/Replaces: base-files (<< 11ubuntu11)
Focal:
ubuntu-server 1.450.2:
Depends: motd-news-config
base-files 11ubuntu5.2:
Breaks: ubuntu-server (<< 1.450.2)
rm_conffile /etc/default/motd-news 11ubuntu5.2~ base-files
motd-news-config 11ubuntu5.2:
Breaks/Replaces: base-files (<< 11ubuntu5.2)
Bionic:
ubuntu-server 1.417.5:
Depends: motd-news-config
base-files 10.1ubuntu2.10:
Breaks: ubuntu-server (<< 1.417.5)
rm_conffile /etc/default/motd-news 10.1ubuntu2.10~ base-files
motd-news-config 10.1ubuntu2.10:
Breaks/Replaces: base-files (<< 10.1ubuntu2.10)
Xenial:
ubuntu-server 1.361.5:
Depends: motd-news-config
base-files 9.4ubuntu4.13:
Breaks: ubuntu-server (<< 1.361.5)
rm_conffile /etc/default/motd-news 9.4ubuntu4.13~ base-files
motd-news-config 9.4ubuntu4.13:
Breaks/Replaces: base-files (<< 9.4ubuntu4.13)
[Other Info]
a) Testcase (i) will leave around an empty /etc/default/motd-news.wasremoved file, created by the base-files postinst. This file is removed by the motd-news-config postinst, but since that package doesn't get installed in that particular scenario, the file remains. I toyed with the idea of adding an extra check to base-file's postinst, like this:
--- a/debian/postinst.in
+++ b/debian/postinst.in
@@ -133,7 +133,11 @@ motd_news_config="/etc/default/motd-news"
if [ ! -e ${motd_news_config} ]; then
if [ ! -e ${motd_news_config}.dpkg-remove ]; then
if [ ! -e ${motd_news_config}.dpkg-backup ]; then
- touch ${motd_news_config}.wasremoved
+ # The .wasremoved file only matters if ubuntu-server is installed,
+ # because that's what will pull in motd-news-config
+ if dpkg -l ubuntu-server 2>/dev/null | grep -q ^i; then
+ touch ${motd_news_config}.wasremoved
+ fi
fi
fi
fi
But deemed it too risky, and not worth further potential regressions. It seemed to work, though, at least for groovy.
b) Currently the xenial cloud images, with the exception of the AWS one, do not have ubuntu-server installed. This means that this SRU will disable motd-news on them, unless ubuntu-server was manually installed for some reason. This includes LXD xenial images as well.
c) The new motd-news-config package has its d/control priority set to "optional", so a release upgrade won't pick it up (presumably the same applies to the installer). I've been told there are archive overrides that might need updating as well: dear SRU team member, please check, or ask an archive admin to check. |
[Impact]
The motd-news script is largely useless for desktop users, as they rarely login via a text console. It makes more sense for server users.
We can use package dependencies to have the motd-news script enabled on servers, but disabled on desktops, and still handle upgrades. This is the plan:
- move /etc/default/motd-news from base-files into a new binary package (motd-news-config, produced by src:base-files)
- have ubuntu-server depend on motd-news-config
- have base-files break current ubuntu-server, so that if base-files if upgraded and ubuntu-server is installed, ubuntu-server will also be upgraded to the new version which has the depends on motd-news-config
Care must be taken to preserve a changed /etc/default/motd-news when the upgrade installs the new motd-news-config package. For example, on a server that has set ENABLED=0 in /etc/default/motd-news and upgrades to the new base-files and ubuntu-server, and gets the new motd-config-news package, ENABLED=0 must remain set.
[Test Case]
a) base-files installed, ubuntu-server installed, unmodified /e/d/motd-news
apt install base-files
- upgrades ubuntu-server
- installs motd-news-config
- /e/d/motd-news remains, motd-news remains enabled
b) base-files installed, ubuntu-server installed, modified /e/d/motd-news
apt install base-files
- upgrades ubuntu-server
- installs motd-news-config
- /e/d/motd-news remains with the original modification
c) base-files installed, ubuntu-server not installed, unmodified /e/d/motd-news
apt install base-files
- upgrades base-files
- removes /e/d/motd-news
- motd-news is disabled
d) base-files installed, ubuntu-server not installed, modified /e/d/motd-news
apt install base-files
- upgrades base-files
- /e/d/motd-news gets renamed to backup
- motd-news is disabled
e) removing motd-news-config will also remove ubuntu-server (since it's a depends, and not a recommends)
f) upgrading just ubuntu-server should pull motd-news-config in, and force-upgrade base-files
g) Removing motd-news-server leaves /e/d/motd-news around; purging motd-news-server removes the /e/d/motd-news config file
h) base-files installed, ubuntu-server installed, removed /e/d/motd-news
- apt install base-files
- upgrades base-files, upgrades ubuntu-server, installs motd-news-config
- /e/d/motd-news is installed with ENABLED=0
i) base-files installed, ubuntu-server NOT installed, removed e/d/motd-news
- apt install base-files
- base-files is upgraded
- no /e/d/motd-news is installed, motd-news remains disabled
j) Perform a release upgrade from the previous ubuntu release to the one being tested while having ubuntu-server NOT installed (or use a desktop install). At the end, motd-news should be disabled. Verify with:
$ sudo /etc/update-motd.d/50-motd-news --force
$ (no output)
[Regression Potential]
This update is about config file ownership transfer: /e/d/motd-news belonged to base-files, now it belongs to motd-news-config. We tried to handle two important cases here:
a) /e/d/motd-news config was changed while it belonged to base-files. For example, an user could have set ENABLED=0. We need to transfer that change to the motd-news-config package when it is installed, otherwise this SRU would jsut re-enabled motd-news. This is handled in d/motd-news-config.postinst's configure case.
b) /e/d/motd-news config file was *removed* while it belonged to base-files. In such a case, a normal upgrade of the package (base-files in this example) would not reinstate the file. Much less this upgrade here, which has an explicit rm_conffile maintscript-helper for it. But the motd-news-config package that could be installed in the transaction would place the default config file back, and the default is ENABLED=1. Thus, a system that had motd-news disabled via removing the config file would now have it re-enabled after the upgrade.
This was trickier to handle, and we do it in base-files's postinst and motd-news-config's postinst. The drawback is that in one scenario, where just base-files is upgraded and /e/d/motd-news was manually removed by the user, there will be a /e/d/motd-news.wasremoved leftover empty file (see "other info" below for details).
In general, the regression risks here are:
- have motd-news enabled again on a system where it was previously disabled. We tried to envision two ways it would have been disabled (set ENABLED=0, and remove the config file). There are probably others
- differences in dpkg and/or debhelper behavior in older ubuntu releases leading to unexpected results (should be covered by the test cases from this SRU)
- xenial in particular is trickier, because src:base-files there does NOT use debhelper, so many of the things we take for granted have to be done by hand
- have some sort of dpkg postinst or dependency error because of unpredicted scenarios. Certain assumptions are being made, like the renames that dpkg-maintscript-helper does, and that the filename /etc/default/motd-news.wasremoved that I'm touching and verifying is really mine and not something that was there already.
- the versions I'm breaking/replacing on, and using rm_conffiles on, must be exact. These are the versions today in the archive (2020-08-12):
base-files:
x: 9.4ubuntu4.12
b: 10.1ubuntu2.9
f: 11ubuntu5.1
g: 11ubuntu12 (was 11ubuntu10)
ubuntu-meta:
x: 1.361.4
b: 1.417.4
f: 1.450.1
g: 1.452
Which reflect in these relationships in the updated packages:
Groovy:
ubuntu-server 1.453:
Depends: motd-news-config
base-files 11ubuntu11:
Breaks: ubuntu-server (<< 1.453)
rm_conffile /etc/default/motd-news 11ubuntu11~ base-files
motd-news-config 11ubuntu11:
Breaks/Replaces: base-files (<< 11ubuntu11)
Focal:
ubuntu-server 1.450.2:
Depends: motd-news-config
base-files 11ubuntu5.2:
Breaks: ubuntu-server (<< 1.450.2)
rm_conffile /etc/default/motd-news 11ubuntu5.2~ base-files
motd-news-config 11ubuntu5.2:
Breaks/Replaces: base-files (<< 11ubuntu5.2)
Bionic:
ubuntu-server 1.417.5:
Depends: motd-news-config
base-files 10.1ubuntu2.10:
Breaks: ubuntu-server (<< 1.417.5)
rm_conffile /etc/default/motd-news 10.1ubuntu2.10~ base-files
motd-news-config 10.1ubuntu2.10:
Breaks/Replaces: base-files (<< 10.1ubuntu2.10)
Xenial:
ubuntu-server 1.361.5:
Depends: motd-news-config
base-files 9.4ubuntu4.13:
Breaks: ubuntu-server (<< 1.361.5)
rm_conffile /etc/default/motd-news 9.4ubuntu4.13~ base-files
motd-news-config 9.4ubuntu4.13:
Breaks/Replaces: base-files (<< 9.4ubuntu4.13)
[Other Info]
a) Testcase (i) will leave around an empty /etc/default/motd-news.wasremoved file, created by the base-files postinst. This file is removed by the motd-news-config postinst, but since that package doesn't get installed in that particular scenario, the file remains. I toyed with the idea of adding an extra check to base-file's postinst, like this:
--- a/debian/postinst.in
+++ b/debian/postinst.in
@@ -133,7 +133,11 @@ motd_news_config="/etc/default/motd-news"
if [ ! -e ${motd_news_config} ]; then
if [ ! -e ${motd_news_config}.dpkg-remove ]; then
if [ ! -e ${motd_news_config}.dpkg-backup ]; then
- touch ${motd_news_config}.wasremoved
+ # The .wasremoved file only matters if ubuntu-server is installed,
+ # because that's what will pull in motd-news-config
+ if dpkg -l ubuntu-server 2>/dev/null | grep -q ^i; then
+ touch ${motd_news_config}.wasremoved
+ fi
fi
fi
fi
But deemed it too risky, and not worth further potential regressions. It seemed to work, though, at least for groovy.
b) Currently the xenial cloud images, with the exception of the AWS one, do not have ubuntu-server installed. This means that this SRU will disable motd-news on them, unless ubuntu-server was manually installed for some reason. This includes LXD xenial images as well.
c) The new motd-news-config package has its d/control priority set to "optional", so a release upgrade won't pick it up (presumably the same applies to the installer). I've been told there are archive overrides that might need updating as well: dear SRU team member, please check, or ask an archive admin to check. |
|
| 2020-08-21 11:07:49 |
Timo Aaltonen |
base-files (Ubuntu Focal): status |
In Progress |
Fix Committed |
|
| 2020-08-21 11:07:52 |
Timo Aaltonen |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2020-08-21 11:07:53 |
Timo Aaltonen |
bug |
|
|
added subscriber SRU Verification |
| 2020-08-21 11:07:57 |
Timo Aaltonen |
tags |
|
verification-needed verification-needed-focal |
|
| 2020-08-21 11:10:45 |
Timo Aaltonen |
base-files (Ubuntu Bionic): status |
In Progress |
Fix Committed |
|
| 2020-08-21 11:10:52 |
Timo Aaltonen |
tags |
verification-needed verification-needed-focal |
verification-needed verification-needed-bionic verification-needed-focal |
|
| 2020-08-21 11:12:23 |
Timo Aaltonen |
base-files (Ubuntu Xenial): status |
In Progress |
Fix Committed |
|
| 2020-08-21 11:12:30 |
Timo Aaltonen |
tags |
verification-needed verification-needed-bionic verification-needed-focal |
verification-needed verification-needed-bionic verification-needed-focal verification-needed-xenial |
|
| 2020-08-24 18:52:50 |
Steve Langasek |
ubuntu-meta (Ubuntu Focal): status |
In Progress |
Fix Committed |
|
| 2020-08-24 19:39:55 |
Steve Langasek |
ubuntu-meta (Ubuntu Bionic): status |
In Progress |
Fix Committed |
|
| 2020-08-24 19:40:49 |
Steve Langasek |
ubuntu-meta (Ubuntu Xenial): status |
In Progress |
Fix Committed |
|
| 2020-08-25 19:09:49 |
Andreas Hasenack |
tags |
verification-needed verification-needed-bionic verification-needed-focal verification-needed-xenial |
verification-done-focal verification-needed verification-needed-bionic verification-needed-xenial |
|
| 2020-08-25 19:10:04 |
Andreas Hasenack |
ubuntu-meta (Ubuntu Groovy): status |
In Progress |
Fix Released |
|
| 2020-08-25 22:05:50 |
Andreas Hasenack |
tags |
verification-done-focal verification-needed verification-needed-bionic verification-needed-xenial |
verification-done-bionic verification-done-focal verification-done-xenial verification-needed |
|
| 2020-08-27 08:50:00 |
Haw Loeung |
bug |
|
|
added subscriber Haw Loeung |
| 2020-08-31 01:53:04 |
Mathew Hodson |
tags |
verification-done-bionic verification-done-focal verification-done-xenial verification-needed |
verification-done-bionic verification-done-focal verification-done-xenial |
|
| 2020-09-02 20:32:59 |
Launchpad Janitor |
ubuntu-meta (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
| 2020-09-02 20:32:56 |
Launchpad Janitor |
base-files (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
| 2020-09-02 20:33:14 |
Steve Langasek |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2020-09-02 20:33:32 |
Launchpad Janitor |
ubuntu-meta (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
| 2020-09-02 20:33:30 |
Launchpad Janitor |
base-files (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
| 2020-09-02 20:34:05 |
Launchpad Janitor |
ubuntu-meta (Ubuntu Focal): status |
Fix Committed |
Fix Released |
|
| 2020-09-02 20:34:02 |
Launchpad Janitor |
base-files (Ubuntu Focal): status |
Fix Committed |
Fix Released |
|
| 2020-09-16 20:39:06 |
Steve Langasek |
bug task added |
|
livecd-rootfs (Ubuntu) |
|
| 2020-09-16 20:40:22 |
Steve Langasek |
livecd-rootfs (Ubuntu Xenial): status |
New |
Invalid |
|
| 2020-09-16 20:40:38 |
Steve Langasek |
livecd-rootfs (Ubuntu Bionic): status |
New |
Invalid |
|
| 2020-09-16 20:40:55 |
Steve Langasek |
livecd-rootfs (Ubuntu Xenial): status |
Invalid |
Triaged |
|
| 2020-09-16 20:41:58 |
Steve Langasek |
livecd-rootfs (Ubuntu Focal): status |
New |
Invalid |
|
| 2020-09-16 20:42:19 |
Steve Langasek |
livecd-rootfs (Ubuntu Groovy): status |
New |
Invalid |
|
| 2020-09-16 20:54:19 |
Cody Shepherd |
description |
[Impact]
The motd-news script is largely useless for desktop users, as they rarely login via a text console. It makes more sense for server users.
We can use package dependencies to have the motd-news script enabled on servers, but disabled on desktops, and still handle upgrades. This is the plan:
- move /etc/default/motd-news from base-files into a new binary package (motd-news-config, produced by src:base-files)
- have ubuntu-server depend on motd-news-config
- have base-files break current ubuntu-server, so that if base-files if upgraded and ubuntu-server is installed, ubuntu-server will also be upgraded to the new version which has the depends on motd-news-config
Care must be taken to preserve a changed /etc/default/motd-news when the upgrade installs the new motd-news-config package. For example, on a server that has set ENABLED=0 in /etc/default/motd-news and upgrades to the new base-files and ubuntu-server, and gets the new motd-config-news package, ENABLED=0 must remain set.
[Test Case]
a) base-files installed, ubuntu-server installed, unmodified /e/d/motd-news
apt install base-files
- upgrades ubuntu-server
- installs motd-news-config
- /e/d/motd-news remains, motd-news remains enabled
b) base-files installed, ubuntu-server installed, modified /e/d/motd-news
apt install base-files
- upgrades ubuntu-server
- installs motd-news-config
- /e/d/motd-news remains with the original modification
c) base-files installed, ubuntu-server not installed, unmodified /e/d/motd-news
apt install base-files
- upgrades base-files
- removes /e/d/motd-news
- motd-news is disabled
d) base-files installed, ubuntu-server not installed, modified /e/d/motd-news
apt install base-files
- upgrades base-files
- /e/d/motd-news gets renamed to backup
- motd-news is disabled
e) removing motd-news-config will also remove ubuntu-server (since it's a depends, and not a recommends)
f) upgrading just ubuntu-server should pull motd-news-config in, and force-upgrade base-files
g) Removing motd-news-server leaves /e/d/motd-news around; purging motd-news-server removes the /e/d/motd-news config file
h) base-files installed, ubuntu-server installed, removed /e/d/motd-news
- apt install base-files
- upgrades base-files, upgrades ubuntu-server, installs motd-news-config
- /e/d/motd-news is installed with ENABLED=0
i) base-files installed, ubuntu-server NOT installed, removed e/d/motd-news
- apt install base-files
- base-files is upgraded
- no /e/d/motd-news is installed, motd-news remains disabled
j) Perform a release upgrade from the previous ubuntu release to the one being tested while having ubuntu-server NOT installed (or use a desktop install). At the end, motd-news should be disabled. Verify with:
$ sudo /etc/update-motd.d/50-motd-news --force
$ (no output)
[Regression Potential]
This update is about config file ownership transfer: /e/d/motd-news belonged to base-files, now it belongs to motd-news-config. We tried to handle two important cases here:
a) /e/d/motd-news config was changed while it belonged to base-files. For example, an user could have set ENABLED=0. We need to transfer that change to the motd-news-config package when it is installed, otherwise this SRU would jsut re-enabled motd-news. This is handled in d/motd-news-config.postinst's configure case.
b) /e/d/motd-news config file was *removed* while it belonged to base-files. In such a case, a normal upgrade of the package (base-files in this example) would not reinstate the file. Much less this upgrade here, which has an explicit rm_conffile maintscript-helper for it. But the motd-news-config package that could be installed in the transaction would place the default config file back, and the default is ENABLED=1. Thus, a system that had motd-news disabled via removing the config file would now have it re-enabled after the upgrade.
This was trickier to handle, and we do it in base-files's postinst and motd-news-config's postinst. The drawback is that in one scenario, where just base-files is upgraded and /e/d/motd-news was manually removed by the user, there will be a /e/d/motd-news.wasremoved leftover empty file (see "other info" below for details).
In general, the regression risks here are:
- have motd-news enabled again on a system where it was previously disabled. We tried to envision two ways it would have been disabled (set ENABLED=0, and remove the config file). There are probably others
- differences in dpkg and/or debhelper behavior in older ubuntu releases leading to unexpected results (should be covered by the test cases from this SRU)
- xenial in particular is trickier, because src:base-files there does NOT use debhelper, so many of the things we take for granted have to be done by hand
- have some sort of dpkg postinst or dependency error because of unpredicted scenarios. Certain assumptions are being made, like the renames that dpkg-maintscript-helper does, and that the filename /etc/default/motd-news.wasremoved that I'm touching and verifying is really mine and not something that was there already.
- the versions I'm breaking/replacing on, and using rm_conffiles on, must be exact. These are the versions today in the archive (2020-08-12):
base-files:
x: 9.4ubuntu4.12
b: 10.1ubuntu2.9
f: 11ubuntu5.1
g: 11ubuntu12 (was 11ubuntu10)
ubuntu-meta:
x: 1.361.4
b: 1.417.4
f: 1.450.1
g: 1.452
Which reflect in these relationships in the updated packages:
Groovy:
ubuntu-server 1.453:
Depends: motd-news-config
base-files 11ubuntu11:
Breaks: ubuntu-server (<< 1.453)
rm_conffile /etc/default/motd-news 11ubuntu11~ base-files
motd-news-config 11ubuntu11:
Breaks/Replaces: base-files (<< 11ubuntu11)
Focal:
ubuntu-server 1.450.2:
Depends: motd-news-config
base-files 11ubuntu5.2:
Breaks: ubuntu-server (<< 1.450.2)
rm_conffile /etc/default/motd-news 11ubuntu5.2~ base-files
motd-news-config 11ubuntu5.2:
Breaks/Replaces: base-files (<< 11ubuntu5.2)
Bionic:
ubuntu-server 1.417.5:
Depends: motd-news-config
base-files 10.1ubuntu2.10:
Breaks: ubuntu-server (<< 1.417.5)
rm_conffile /etc/default/motd-news 10.1ubuntu2.10~ base-files
motd-news-config 10.1ubuntu2.10:
Breaks/Replaces: base-files (<< 10.1ubuntu2.10)
Xenial:
ubuntu-server 1.361.5:
Depends: motd-news-config
base-files 9.4ubuntu4.13:
Breaks: ubuntu-server (<< 1.361.5)
rm_conffile /etc/default/motd-news 9.4ubuntu4.13~ base-files
motd-news-config 9.4ubuntu4.13:
Breaks/Replaces: base-files (<< 9.4ubuntu4.13)
[Other Info]
a) Testcase (i) will leave around an empty /etc/default/motd-news.wasremoved file, created by the base-files postinst. This file is removed by the motd-news-config postinst, but since that package doesn't get installed in that particular scenario, the file remains. I toyed with the idea of adding an extra check to base-file's postinst, like this:
--- a/debian/postinst.in
+++ b/debian/postinst.in
@@ -133,7 +133,11 @@ motd_news_config="/etc/default/motd-news"
if [ ! -e ${motd_news_config} ]; then
if [ ! -e ${motd_news_config}.dpkg-remove ]; then
if [ ! -e ${motd_news_config}.dpkg-backup ]; then
- touch ${motd_news_config}.wasremoved
+ # The .wasremoved file only matters if ubuntu-server is installed,
+ # because that's what will pull in motd-news-config
+ if dpkg -l ubuntu-server 2>/dev/null | grep -q ^i; then
+ touch ${motd_news_config}.wasremoved
+ fi
fi
fi
fi
But deemed it too risky, and not worth further potential regressions. It seemed to work, though, at least for groovy.
b) Currently the xenial cloud images, with the exception of the AWS one, do not have ubuntu-server installed. This means that this SRU will disable motd-news on them, unless ubuntu-server was manually installed for some reason. This includes LXD xenial images as well.
c) The new motd-news-config package has its d/control priority set to "optional", so a release upgrade won't pick it up (presumably the same applies to the installer). I've been told there are archive overrides that might need updating as well: dear SRU team member, please check, or ask an archive admin to check. |
[Impact]
The motd-news script is largely useless for desktop users, as they rarely login via a text console. It makes more sense for server users.
We can use package dependencies to have the motd-news script enabled on servers, but disabled on desktops, and still handle upgrades. This is the plan:
- move /etc/default/motd-news from base-files into a new binary package (motd-news-config, produced by src:base-files)
- have ubuntu-server depend on motd-news-config
- have base-files break current ubuntu-server, so that if base-files if upgraded and ubuntu-server is installed, ubuntu-server will also be upgraded to the new version which has the depends on motd-news-config
Care must be taken to preserve a changed /etc/default/motd-news when the upgrade installs the new motd-news-config package. For example, on a server that has set ENABLED=0 in /etc/default/motd-news and upgrades to the new base-files and ubuntu-server, and gets the new motd-config-news package, ENABLED=0 must remain set.
[Test Case]
a) base-files installed, ubuntu-server installed, unmodified /e/d/motd-news
apt install base-files
- upgrades ubuntu-server
- installs motd-news-config
- /e/d/motd-news remains, motd-news remains enabled
b) base-files installed, ubuntu-server installed, modified /e/d/motd-news
apt install base-files
- upgrades ubuntu-server
- installs motd-news-config
- /e/d/motd-news remains with the original modification
c) base-files installed, ubuntu-server not installed, unmodified /e/d/motd-news
apt install base-files
- upgrades base-files
- removes /e/d/motd-news
- motd-news is disabled
d) base-files installed, ubuntu-server not installed, modified /e/d/motd-news
apt install base-files
- upgrades base-files
- /e/d/motd-news gets renamed to backup
- motd-news is disabled
e) removing motd-news-config will also remove ubuntu-server (since it's a depends, and not a recommends)
f) upgrading just ubuntu-server should pull motd-news-config in, and force-upgrade base-files
g) Removing motd-news-server leaves /e/d/motd-news around; purging motd-news-server removes the /e/d/motd-news config file
h) base-files installed, ubuntu-server installed, removed /e/d/motd-news
- apt install base-files
- upgrades base-files, upgrades ubuntu-server, installs motd-news-config
- /e/d/motd-news is installed with ENABLED=0
i) base-files installed, ubuntu-server NOT installed, removed e/d/motd-news
- apt install base-files
- base-files is upgraded
- no /e/d/motd-news is installed, motd-news remains disabled
j) Perform a release upgrade from the previous ubuntu release to the one being tested while having ubuntu-server NOT installed (or use a desktop install). At the end, motd-news should be disabled. Verify with:
$ sudo /etc/update-motd.d/50-motd-news --force
$ (no output)
k) Test that supporting changes for xenial are in place:
i) verify grub-legacy-ec2 is not in the xenial server seed
ii) verify that the rootfs manifest built from the ubuntu-cpc project contains the ubuntu-server package
iii) verify that images built from the ubuntu-cpc project which purge grub-legacy-ec2 have retained ubuntu-server
[Regression Potential]
This update is about config file ownership transfer: /e/d/motd-news belonged to base-files, now it belongs to motd-news-config. We tried to handle two important cases here:
a) /e/d/motd-news config was changed while it belonged to base-files. For example, an user could have set ENABLED=0. We need to transfer that change to the motd-news-config package when it is installed, otherwise this SRU would jsut re-enabled motd-news. This is handled in d/motd-news-config.postinst's configure case.
b) /e/d/motd-news config file was *removed* while it belonged to base-files. In such a case, a normal upgrade of the package (base-files in this example) would not reinstate the file. Much less this upgrade here, which has an explicit rm_conffile maintscript-helper for it. But the motd-news-config package that could be installed in the transaction would place the default config file back, and the default is ENABLED=1. Thus, a system that had motd-news disabled via removing the config file would now have it re-enabled after the upgrade.
This was trickier to handle, and we do it in base-files's postinst and motd-news-config's postinst. The drawback is that in one scenario, where just base-files is upgraded and /e/d/motd-news was manually removed by the user, there will be a /e/d/motd-news.wasremoved leftover empty file (see "other info" below for details).
In general, the regression risks here are:
- have motd-news enabled again on a system where it was previously disabled. We tried to envision two ways it would have been disabled (set ENABLED=0, and remove the config file). There are probably others
- differences in dpkg and/or debhelper behavior in older ubuntu releases leading to unexpected results (should be covered by the test cases from this SRU)
- xenial in particular is trickier, because src:base-files there does NOT use debhelper, so many of the things we take for granted have to be done by hand
- have some sort of dpkg postinst or dependency error because of unpredicted scenarios. Certain assumptions are being made, like the renames that dpkg-maintscript-helper does, and that the filename /etc/default/motd-news.wasremoved that I'm touching and verifying is really mine and not something that was there already.
- the versions I'm breaking/replacing on, and using rm_conffiles on, must be exact. These are the versions today in the archive (2020-08-12):
base-files:
x: 9.4ubuntu4.12
b: 10.1ubuntu2.9
f: 11ubuntu5.1
g: 11ubuntu12 (was 11ubuntu10)
ubuntu-meta:
x: 1.361.4
b: 1.417.4
f: 1.450.1
g: 1.452
Which reflect in these relationships in the updated packages:
Groovy:
ubuntu-server 1.453:
Depends: motd-news-config
base-files 11ubuntu11:
Breaks: ubuntu-server (<< 1.453)
rm_conffile /etc/default/motd-news 11ubuntu11~ base-files
motd-news-config 11ubuntu11:
Breaks/Replaces: base-files (<< 11ubuntu11)
Focal:
ubuntu-server 1.450.2:
Depends: motd-news-config
base-files 11ubuntu5.2:
Breaks: ubuntu-server (<< 1.450.2)
rm_conffile /etc/default/motd-news 11ubuntu5.2~ base-files
motd-news-config 11ubuntu5.2:
Breaks/Replaces: base-files (<< 11ubuntu5.2)
Bionic:
ubuntu-server 1.417.5:
Depends: motd-news-config
base-files 10.1ubuntu2.10:
Breaks: ubuntu-server (<< 1.417.5)
rm_conffile /etc/default/motd-news 10.1ubuntu2.10~ base-files
motd-news-config 10.1ubuntu2.10:
Breaks/Replaces: base-files (<< 10.1ubuntu2.10)
Xenial:
ubuntu-server 1.361.5:
Depends: motd-news-config
base-files 9.4ubuntu4.13:
Breaks: ubuntu-server (<< 1.361.5)
rm_conffile /etc/default/motd-news 9.4ubuntu4.13~ base-files
motd-news-config 9.4ubuntu4.13:
Breaks/Replaces: base-files (<< 9.4ubuntu4.13)
[Other Info]
a) Testcase (i) will leave around an empty /etc/default/motd-news.wasremoved file, created by the base-files postinst. This file is removed by the motd-news-config postinst, but since that package doesn't get installed in that particular scenario, the file remains. I toyed with the idea of adding an extra check to base-file's postinst, like this:
--- a/debian/postinst.in
+++ b/debian/postinst.in
@@ -133,7 +133,11 @@ motd_news_config="/etc/default/motd-news"
if [ ! -e ${motd_news_config} ]; then
if [ ! -e ${motd_news_config}.dpkg-remove ]; then
if [ ! -e ${motd_news_config}.dpkg-backup ]; then
- touch ${motd_news_config}.wasremoved
+ # The .wasremoved file only matters if ubuntu-server is installed,
+ # because that's what will pull in motd-news-config
+ if dpkg -l ubuntu-server 2>/dev/null | grep -q ^i; then
+ touch ${motd_news_config}.wasremoved
+ fi
fi
fi
fi
But deemed it too risky, and not worth further potential regressions. It seemed to work, though, at least for groovy.
b) Currently the xenial cloud images, with the exception of the AWS one, do not have ubuntu-server installed. This means that this SRU will disable motd-news on them, unless ubuntu-server was manually installed for some reason. This includes LXD xenial images as well.
c) The new motd-news-config package has its d/control priority set to "optional", so a release upgrade won't pick it up (presumably the same applies to the installer). I've been told there are archive overrides that might need updating as well: dear SRU team member, please check, or ask an archive admin to check. |
|
| 2020-09-21 10:54:25 |
Łukasz Zemczak |
ubuntu-meta (Ubuntu Xenial): status |
Fix Released |
Fix Committed |
|
| 2020-09-21 10:54:29 |
Łukasz Zemczak |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2020-09-21 10:54:34 |
Łukasz Zemczak |
tags |
verification-done-bionic verification-done-focal verification-done-xenial |
verification-done-bionic verification-done-focal verification-needed verification-needed-xenial |
|
| 2020-09-22 10:30:35 |
Oliver Grawert |
bug watch added |
|
https://github.com/snapcore/core18/issues/170 |
|
| 2020-09-23 20:43:30 |
Steve Langasek |
description |
[Impact]
The motd-news script is largely useless for desktop users, as they rarely login via a text console. It makes more sense for server users.
We can use package dependencies to have the motd-news script enabled on servers, but disabled on desktops, and still handle upgrades. This is the plan:
- move /etc/default/motd-news from base-files into a new binary package (motd-news-config, produced by src:base-files)
- have ubuntu-server depend on motd-news-config
- have base-files break current ubuntu-server, so that if base-files if upgraded and ubuntu-server is installed, ubuntu-server will also be upgraded to the new version which has the depends on motd-news-config
Care must be taken to preserve a changed /etc/default/motd-news when the upgrade installs the new motd-news-config package. For example, on a server that has set ENABLED=0 in /etc/default/motd-news and upgrades to the new base-files and ubuntu-server, and gets the new motd-config-news package, ENABLED=0 must remain set.
[Test Case]
a) base-files installed, ubuntu-server installed, unmodified /e/d/motd-news
apt install base-files
- upgrades ubuntu-server
- installs motd-news-config
- /e/d/motd-news remains, motd-news remains enabled
b) base-files installed, ubuntu-server installed, modified /e/d/motd-news
apt install base-files
- upgrades ubuntu-server
- installs motd-news-config
- /e/d/motd-news remains with the original modification
c) base-files installed, ubuntu-server not installed, unmodified /e/d/motd-news
apt install base-files
- upgrades base-files
- removes /e/d/motd-news
- motd-news is disabled
d) base-files installed, ubuntu-server not installed, modified /e/d/motd-news
apt install base-files
- upgrades base-files
- /e/d/motd-news gets renamed to backup
- motd-news is disabled
e) removing motd-news-config will also remove ubuntu-server (since it's a depends, and not a recommends)
f) upgrading just ubuntu-server should pull motd-news-config in, and force-upgrade base-files
g) Removing motd-news-server leaves /e/d/motd-news around; purging motd-news-server removes the /e/d/motd-news config file
h) base-files installed, ubuntu-server installed, removed /e/d/motd-news
- apt install base-files
- upgrades base-files, upgrades ubuntu-server, installs motd-news-config
- /e/d/motd-news is installed with ENABLED=0
i) base-files installed, ubuntu-server NOT installed, removed e/d/motd-news
- apt install base-files
- base-files is upgraded
- no /e/d/motd-news is installed, motd-news remains disabled
j) Perform a release upgrade from the previous ubuntu release to the one being tested while having ubuntu-server NOT installed (or use a desktop install). At the end, motd-news should be disabled. Verify with:
$ sudo /etc/update-motd.d/50-motd-news --force
$ (no output)
k) Test that supporting changes for xenial are in place:
i) verify grub-legacy-ec2 is not in the xenial server seed
ii) verify that the rootfs manifest built from the ubuntu-cpc project contains the ubuntu-server package
iii) verify that images built from the ubuntu-cpc project which purge grub-legacy-ec2 have retained ubuntu-server
[Regression Potential]
This update is about config file ownership transfer: /e/d/motd-news belonged to base-files, now it belongs to motd-news-config. We tried to handle two important cases here:
a) /e/d/motd-news config was changed while it belonged to base-files. For example, an user could have set ENABLED=0. We need to transfer that change to the motd-news-config package when it is installed, otherwise this SRU would jsut re-enabled motd-news. This is handled in d/motd-news-config.postinst's configure case.
b) /e/d/motd-news config file was *removed* while it belonged to base-files. In such a case, a normal upgrade of the package (base-files in this example) would not reinstate the file. Much less this upgrade here, which has an explicit rm_conffile maintscript-helper for it. But the motd-news-config package that could be installed in the transaction would place the default config file back, and the default is ENABLED=1. Thus, a system that had motd-news disabled via removing the config file would now have it re-enabled after the upgrade.
This was trickier to handle, and we do it in base-files's postinst and motd-news-config's postinst. The drawback is that in one scenario, where just base-files is upgraded and /e/d/motd-news was manually removed by the user, there will be a /e/d/motd-news.wasremoved leftover empty file (see "other info" below for details).
In general, the regression risks here are:
- have motd-news enabled again on a system where it was previously disabled. We tried to envision two ways it would have been disabled (set ENABLED=0, and remove the config file). There are probably others
- differences in dpkg and/or debhelper behavior in older ubuntu releases leading to unexpected results (should be covered by the test cases from this SRU)
- xenial in particular is trickier, because src:base-files there does NOT use debhelper, so many of the things we take for granted have to be done by hand
- have some sort of dpkg postinst or dependency error because of unpredicted scenarios. Certain assumptions are being made, like the renames that dpkg-maintscript-helper does, and that the filename /etc/default/motd-news.wasremoved that I'm touching and verifying is really mine and not something that was there already.
- the versions I'm breaking/replacing on, and using rm_conffiles on, must be exact. These are the versions today in the archive (2020-08-12):
base-files:
x: 9.4ubuntu4.12
b: 10.1ubuntu2.9
f: 11ubuntu5.1
g: 11ubuntu12 (was 11ubuntu10)
ubuntu-meta:
x: 1.361.4
b: 1.417.4
f: 1.450.1
g: 1.452
Which reflect in these relationships in the updated packages:
Groovy:
ubuntu-server 1.453:
Depends: motd-news-config
base-files 11ubuntu11:
Breaks: ubuntu-server (<< 1.453)
rm_conffile /etc/default/motd-news 11ubuntu11~ base-files
motd-news-config 11ubuntu11:
Breaks/Replaces: base-files (<< 11ubuntu11)
Focal:
ubuntu-server 1.450.2:
Depends: motd-news-config
base-files 11ubuntu5.2:
Breaks: ubuntu-server (<< 1.450.2)
rm_conffile /etc/default/motd-news 11ubuntu5.2~ base-files
motd-news-config 11ubuntu5.2:
Breaks/Replaces: base-files (<< 11ubuntu5.2)
Bionic:
ubuntu-server 1.417.5:
Depends: motd-news-config
base-files 10.1ubuntu2.10:
Breaks: ubuntu-server (<< 1.417.5)
rm_conffile /etc/default/motd-news 10.1ubuntu2.10~ base-files
motd-news-config 10.1ubuntu2.10:
Breaks/Replaces: base-files (<< 10.1ubuntu2.10)
Xenial:
ubuntu-server 1.361.5:
Depends: motd-news-config
base-files 9.4ubuntu4.13:
Breaks: ubuntu-server (<< 1.361.5)
rm_conffile /etc/default/motd-news 9.4ubuntu4.13~ base-files
motd-news-config 9.4ubuntu4.13:
Breaks/Replaces: base-files (<< 9.4ubuntu4.13)
[Other Info]
a) Testcase (i) will leave around an empty /etc/default/motd-news.wasremoved file, created by the base-files postinst. This file is removed by the motd-news-config postinst, but since that package doesn't get installed in that particular scenario, the file remains. I toyed with the idea of adding an extra check to base-file's postinst, like this:
--- a/debian/postinst.in
+++ b/debian/postinst.in
@@ -133,7 +133,11 @@ motd_news_config="/etc/default/motd-news"
if [ ! -e ${motd_news_config} ]; then
if [ ! -e ${motd_news_config}.dpkg-remove ]; then
if [ ! -e ${motd_news_config}.dpkg-backup ]; then
- touch ${motd_news_config}.wasremoved
+ # The .wasremoved file only matters if ubuntu-server is installed,
+ # because that's what will pull in motd-news-config
+ if dpkg -l ubuntu-server 2>/dev/null | grep -q ^i; then
+ touch ${motd_news_config}.wasremoved
+ fi
fi
fi
fi
But deemed it too risky, and not worth further potential regressions. It seemed to work, though, at least for groovy.
b) Currently the xenial cloud images, with the exception of the AWS one, do not have ubuntu-server installed. This means that this SRU will disable motd-news on them, unless ubuntu-server was manually installed for some reason. This includes LXD xenial images as well.
c) The new motd-news-config package has its d/control priority set to "optional", so a release upgrade won't pick it up (presumably the same applies to the installer). I've been told there are archive overrides that might need updating as well: dear SRU team member, please check, or ask an archive admin to check. |
[Impact]
The motd-news script is largely useless for desktop users, as they rarely login via a text console. It makes more sense for server users.
We can use package dependencies to have the motd-news script enabled on servers, but disabled on desktops, and still handle upgrades. This is the plan:
- move /etc/default/motd-news from base-files into a new binary package (motd-news-config, produced by src:base-files)
- have ubuntu-server depend on motd-news-config
- have base-files break current ubuntu-server, so that if base-files if upgraded and ubuntu-server is installed, ubuntu-server will also be upgraded to the new version which has the depends on motd-news-config
Care must be taken to preserve a changed /etc/default/motd-news when the upgrade installs the new motd-news-config package. For example, on a server that has set ENABLED=0 in /etc/default/motd-news and upgrades to the new base-files and ubuntu-server, and gets the new motd-config-news package, ENABLED=0 must remain set.
[Test Case]
a) base-files installed, ubuntu-server installed, unmodified /e/d/motd-news
apt install base-files
- upgrades ubuntu-server
- installs motd-news-config
- /e/d/motd-news remains, motd-news remains enabled
b) base-files installed, ubuntu-server installed, modified /e/d/motd-news
apt install base-files
- upgrades ubuntu-server
- installs motd-news-config
- /e/d/motd-news remains with the original modification
c) base-files installed, ubuntu-server not installed, unmodified /e/d/motd-news
apt install base-files
- upgrades base-files
- removes /e/d/motd-news
- motd-news is disabled
d) base-files installed, ubuntu-server not installed, modified /e/d/motd-news
apt install base-files
- upgrades base-files
- /e/d/motd-news gets renamed to backup
- motd-news is disabled
e) removing motd-news-config will also remove ubuntu-server (since it's a depends, and not a recommends)
f) upgrading just ubuntu-server should pull motd-news-config in, and force-upgrade base-files
g) Removing motd-news-server leaves /e/d/motd-news around; purging motd-news-server removes the /e/d/motd-news config file
h) base-files installed, ubuntu-server installed, removed /e/d/motd-news
- apt install base-files
- upgrades base-files, upgrades ubuntu-server, installs motd-news-config
- /e/d/motd-news is installed with ENABLED=0
i) base-files installed, ubuntu-server NOT installed, removed e/d/motd-news
- apt install base-files
- base-files is upgraded
- no /e/d/motd-news is installed, motd-news remains disabled
j) Perform a release upgrade from the previous ubuntu release to the one being tested while having ubuntu-server NOT installed (or use a desktop install). At the end, motd-news should be disabled. Verify with:
$ sudo /etc/update-motd.d/50-motd-news --force
$ (no output)
k) Test that supporting changes for xenial are in place:
i) verify grub-legacy-ec2 is not in the xenial server seed
ii) verify that the rootfs manifest built from the ubuntu-cpc project contains the ubuntu-server package
iii) verify that images built from the ubuntu-cpc project which purge grub-legacy-ec2 have retained ubuntu-server
iv) verify that the base ubuntu-cpc image continues to have grub-legacy-ec2 installed.
[Regression Potential]
This update is about config file ownership transfer: /e/d/motd-news belonged to base-files, now it belongs to motd-news-config. We tried to handle two important cases here:
a) /e/d/motd-news config was changed while it belonged to base-files. For example, an user could have set ENABLED=0. We need to transfer that change to the motd-news-config package when it is installed, otherwise this SRU would jsut re-enabled motd-news. This is handled in d/motd-news-config.postinst's configure case.
b) /e/d/motd-news config file was *removed* while it belonged to base-files. In such a case, a normal upgrade of the package (base-files in this example) would not reinstate the file. Much less this upgrade here, which has an explicit rm_conffile maintscript-helper for it. But the motd-news-config package that could be installed in the transaction would place the default config file back, and the default is ENABLED=1. Thus, a system that had motd-news disabled via removing the config file would now have it re-enabled after the upgrade.
This was trickier to handle, and we do it in base-files's postinst and motd-news-config's postinst. The drawback is that in one scenario, where just base-files is upgraded and /e/d/motd-news was manually removed by the user, there will be a /e/d/motd-news.wasremoved leftover empty file (see "other info" below for details).
In general, the regression risks here are:
- have motd-news enabled again on a system where it was previously disabled. We tried to envision two ways it would have been disabled (set ENABLED=0, and remove the config file). There are probably others
- differences in dpkg and/or debhelper behavior in older ubuntu releases leading to unexpected results (should be covered by the test cases from this SRU)
- xenial in particular is trickier, because src:base-files there does NOT use debhelper, so many of the things we take for granted have to be done by hand
- have some sort of dpkg postinst or dependency error because of unpredicted scenarios. Certain assumptions are being made, like the renames that dpkg-maintscript-helper does, and that the filename /etc/default/motd-news.wasremoved that I'm touching and verifying is really mine and not something that was there already.
- the versions I'm breaking/replacing on, and using rm_conffiles on, must be exact. These are the versions today in the archive (2020-08-12):
base-files:
x: 9.4ubuntu4.12
b: 10.1ubuntu2.9
f: 11ubuntu5.1
g: 11ubuntu12 (was 11ubuntu10)
ubuntu-meta:
x: 1.361.4
b: 1.417.4
f: 1.450.1
g: 1.452
Which reflect in these relationships in the updated packages:
Groovy:
ubuntu-server 1.453:
Depends: motd-news-config
base-files 11ubuntu11:
Breaks: ubuntu-server (<< 1.453)
rm_conffile /etc/default/motd-news 11ubuntu11~ base-files
motd-news-config 11ubuntu11:
Breaks/Replaces: base-files (<< 11ubuntu11)
Focal:
ubuntu-server 1.450.2:
Depends: motd-news-config
base-files 11ubuntu5.2:
Breaks: ubuntu-server (<< 1.450.2)
rm_conffile /etc/default/motd-news 11ubuntu5.2~ base-files
motd-news-config 11ubuntu5.2:
Breaks/Replaces: base-files (<< 11ubuntu5.2)
Bionic:
ubuntu-server 1.417.5:
Depends: motd-news-config
base-files 10.1ubuntu2.10:
Breaks: ubuntu-server (<< 1.417.5)
rm_conffile /etc/default/motd-news 10.1ubuntu2.10~ base-files
motd-news-config 10.1ubuntu2.10:
Breaks/Replaces: base-files (<< 10.1ubuntu2.10)
Xenial:
ubuntu-server 1.361.5:
Depends: motd-news-config
base-files 9.4ubuntu4.13:
Breaks: ubuntu-server (<< 1.361.5)
rm_conffile /etc/default/motd-news 9.4ubuntu4.13~ base-files
motd-news-config 9.4ubuntu4.13:
Breaks/Replaces: base-files (<< 9.4ubuntu4.13)
[Other Info]
a) Testcase (i) will leave around an empty /etc/default/motd-news.wasremoved file, created by the base-files postinst. This file is removed by the motd-news-config postinst, but since that package doesn't get installed in that particular scenario, the file remains. I toyed with the idea of adding an extra check to base-file's postinst, like this:
--- a/debian/postinst.in
+++ b/debian/postinst.in
@@ -133,7 +133,11 @@ motd_news_config="/etc/default/motd-news"
if [ ! -e ${motd_news_config} ]; then
if [ ! -e ${motd_news_config}.dpkg-remove ]; then
if [ ! -e ${motd_news_config}.dpkg-backup ]; then
- touch ${motd_news_config}.wasremoved
+ # The .wasremoved file only matters if ubuntu-server is installed,
+ # because that's what will pull in motd-news-config
+ if dpkg -l ubuntu-server 2>/dev/null | grep -q ^i; then
+ touch ${motd_news_config}.wasremoved
+ fi
fi
fi
fi
But deemed it too risky, and not worth further potential regressions. It seemed to work, though, at least for groovy.
b) Currently the xenial cloud images, with the exception of the AWS one, do not have ubuntu-server installed. This means that this SRU will disable motd-news on them, unless ubuntu-server was manually installed for some reason. This includes LXD xenial images as well.
c) The new motd-news-config package has its d/control priority set to "optional", so a release upgrade won't pick it up (presumably the same applies to the installer). I've been told there are archive overrides that might need updating as well: dear SRU team member, please check, or ask an archive admin to check. |
|
| 2020-09-23 20:44:43 |
Steve Langasek |
livecd-rootfs (Ubuntu Xenial): status |
Triaged |
Fix Committed |
|
| 2020-10-07 16:56:16 |
Steve Langasek |
tags |
verification-done-bionic verification-done-focal verification-needed verification-needed-xenial |
verification-done-bionic verification-done-focal verification-done-xenial |
|
| 2020-10-07 16:57:20 |
Launchpad Janitor |
ubuntu-meta (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
| 2020-10-07 16:57:44 |
Steve Langasek |
livecd-rootfs (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
