Bug#932644: reconfigure writes to /usr/lib/locale/locale-archive

2019-07-24 Thread Marc Haber
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

2019-07-24 Thread Aurelien Jarno
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



Bug#910669: glibc: Please remove transitional package multiarch-support

2019-07-24 Thread Boyuan Yang
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


Processed: Re: Bug#910669: glibc: Please remove transitional package multiarch-support

2019-07-24 Thread Debian Bug Tracking System
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

2019-07-24 Thread 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.

> 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 Thread Boyuan Yang
在 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