Bug#932644: reconfigure writes to /usr/lib/locale/locale-archive
On Mon, Jul 22, 2019 at 07:20:42PM +0200, Aurelien Jarno wrote: > On 2019-07-21 17:11, Marc Haber wrote: > > Package: locales > > Version: 2.28-10 > > Severity: minor > > > > Hi, > > > > reconfiguring the locales package updates the file > > /usr/lib/locale/locale-archive. > > This is indeed where the libc looks for the compiled locales. And it wouldn't follow a symlink to /var/lib/locale/locale-archive, where variable data would belong? > > I am not sure whether this is allowed by policy, hence severity: minor. > > I do not find anything that prevents that in the policy. In addition > many other packages are also writing files to /usr when they are > configured (for example __pycache__ files or the various kernel > modules.* files used by depmod, udev hwdb.bin, etc.). But they only do that on package installation. And: "look, how bad the neighbor is" is hardly an excuse. I happened to stumble upon that in locales, and it's the first time that I actually noticed that. > > Maybe this file would better be in /var. > > /var is for files whose content is expected to continually change during > normal operation of the system. This is not the case of the > locale-archive file which doesn't change until the next reconfiguration > of the package. As such it doesn't prevent for example mounting the / or > /usr partition read-only once apt or dpkg have finished their work. You're of course entitled to your opinion and I respect the decision. Just assume: - ansible/puppet/salt etc has a /etc/locale.gen which for some reason doesn't have the current set of comments - a handler calls dpkg-reconfigure locales to handle the change in /etc/locale.gen - locales rewrites /etc/locale.gen with the current set of comments - ansible/puppet/salt runs again, notices that /etc/locale.gen is not as it should be according to its opinion - repeat starting with step 1 locales' current behavior forces people to have the /etc/locale.gen file with current comments in the configuraiton management code, and possible to have this "current" differently according to whether we have oldoldstable, oldstable, stable, testing od unstable. This is unnecessary work and might cause unnecessary issues. Please reconsider. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#932644: reconfigure writes to /usr/lib/locale/locale-archive
On 2019-07-24 12:38, Marc Haber wrote: > On Mon, Jul 22, 2019 at 07:20:42PM +0200, Aurelien Jarno wrote: > > On 2019-07-21 17:11, Marc Haber wrote: > > > Package: locales > > > Version: 2.28-10 > > > Severity: minor > > > > > > Hi, > > > > > > reconfiguring the locales package updates the file > > > /usr/lib/locale/locale-archive. > > > > This is indeed where the libc looks for the compiled locales. > > And it wouldn't follow a symlink to /var/lib/locale/locale-archive, > where variable data would belong? As said in my previous mail, those are not variable data, I do not see the point of moving them to /var. They are only modified when the locales postinst script is run. > > > I am not sure whether this is allowed by policy, hence severity: minor. > > > > I do not find anything that prevents that in the policy. In addition > > many other packages are also writing files to /usr when they are > > configured (for example __pycache__ files or the various kernel > > modules.* files used by depmod, udev hwdb.bin, etc.). > > But they only do that on package installation. And: "look, how bad the > neighbor is" is hardly an excuse. I happened to stumble upon that in > locales, and it's the first time that I actually noticed that. They do that exactly in the same situation than the locales postinst, ie when the package is (re)configured. There is nothing in the policy forbidding that. We can open a bug against the policy to confirm or infirm that. > > > Maybe this file would better be in /var. > > > > /var is for files whose content is expected to continually change during > > normal operation of the system. This is not the case of the > > locale-archive file which doesn't change until the next reconfiguration > > of the package. As such it doesn't prevent for example mounting the / or > > /usr partition read-only once apt or dpkg have finished their work. > > You're of course entitled to your opinion and I respect the decision. > > Just assume: > > - ansible/puppet/salt etc has a /etc/locale.gen which for some reason > doesn't have the current set of comments > - a handler calls dpkg-reconfigure locales to handle the change in > /etc/locale.gen > - locales rewrites /etc/locale.gen with the current set of comments > - ansible/puppet/salt runs again, notices that /etc/locale.gen is not as > it should be according to its opinion > - repeat starting with step 1 Looks like that is for the wrong bug report... -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Processed: Re: Bug#910669: glibc: Please remove transitional package multiarch-support
Processing control commands: > severity -1 normal Bug #910669 [src:glibc] glibc: Please remove transitional package multiarch-support Ignoring request to change severity of Bug 910669 to the same value. > tag -1 - wontfix Bug #910669 [src:glibc] glibc: Please remove transitional package multiarch-support Removed tag(s) wontfix. -- 910669: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910669 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#910669: glibc: Please remove transitional package multiarch-support
Control: severity -1 normal Control: tag -1 - wontfix X-Debbugs-CC: aurel...@aurel32.net Hi Aurelien and other Debian glibc maintainers, With Debian Buster released, I think now we are absolutely safe to have package multiach-support removed from Sid (and thus Testing). There's no other package in Sid (and Testing) currently depends on it. I can help submit a removal request to FTP Masters if you find it okay. Regards, Boyuan Yang On Tue, 9 Oct 2018 17:01:03 +0200 Aurelien Jarno wrote: > control: severity -1 + wishlist > control: tag -1 + wontfix > > On 2018-10-09 10:17, Boyuan Yang wrote: > > Source: glibc > > Version: 2.27-6 > > X-Debbugs-CC: aure...@debian.org d...@debian.org > > Severity: normal > > > > Hi Aurelien, Matthias and Debian glibc maintainers, > > > > As previously discussed in > > https://lists.debian.org/debian-science/2018/08/msg00050.html , > > I think it's time to completely remove multiarch-support from Sid (and > > thus Buster). > > That was my original plan, however the release team rejected that plan > on IRC. A few packages in Stretch still depends on multiarch-support, so > that might cause issues with apt during upgrade to Buster. This can > therefore be only removed after Buster is released. Tagging the bug as > wontfix in the meantime. > > -- > Aurelien Jarno GPG: 4096R/1DDD8C9B > aurel...@aurel32.net http://www.aurel32.net signature.asc Description: This is a digitally signed message part
Bug#910669: glibc: Please remove transitional package multiarch-support
On 2019-07-24 12:01, Boyuan Yang wrote: > Control: severity -1 normal > Control: tag -1 - wontfix > X-Debbugs-CC: aurel...@aurel32.net > > Hi Aurelien and other Debian glibc maintainers, > > With Debian Buster released, I think now we are absolutely safe to have > package multiach-support removed from Sid (and thus Testing). There's no other Agreed, that will be done in one of the next uploads of the glibc package. > package in Sid (and Testing) currently depends on it. I can help submit a That is true for testing. For sid there is still: - hidrd on armel, armhf, ppc64el and s390x - librevisa on s390x For experimental there is still: - poti on armel, armhf ans 390x > removal request to FTP Masters if you find it okay. There is no need to submit a removal request for that. What is needed is to upload a new version of the glibc package without multiarch-support. Then it will be removed once no other packages depends on it in the archive. OTOH you can help to get the above packages removed by filling a removal request to FTP masters. Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Bug#910669: glibc: Please remove transitional package multiarch-support
在 2019-07-24三的 19:00 +0200，Aurelien Jarno写道： > On 2019-07-24 12:01, Boyuan Yang wrote: > > Control: severity -1 normal > > Control: tag -1 - wontfix > > X-Debbugs-CC: aurel...@aurel32.net > > > > Hi Aurelien and other Debian glibc maintainers, > > > > With Debian Buster released, I think now we are absolutely safe to have > > package multiach-support removed from Sid (and thus Testing). There's no > > other > > Agreed, that will be done in one of the next uploads of the glibc > package. Thanks! > > package in Sid (and Testing) currently depends on it. I can help submit a > > That is true for testing. > > For sid there is still: > - hidrd on armel, armhf, ppc64el and s390x > - librevisa on s390x > > For experimental there is still: > - poti on armel, armhf ans 390x > > > > removal request to FTP Masters if you find it okay. > > There is no need to submit a removal request for that. What is needed is > to upload a new version of the glibc package without multiarch-support. > Then it will be removed once no other packages depends on it in the > archive. OTOH you can help to get the above packages removed by filling > a removal request to FTP masters. Oops I forgot to check architectures other than amd64 (and that such removal do not need to involve FTP Masters). With those reverse dependencies left, multiarch-support could become a leftover cruft on certain architectures if those old packages are not removed; anyway it should be checked later after new glibc upload. Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
