Re: future of aufs in Debian.
On Wed, May 27, 2020 at 02:30:39PM -0700, Noah Meyerhans wrote: > On Tue, May 26, 2020 at 05:10:10PM +0300, Adrian Bunk wrote: > > > Adrian filed a rc bug in November 2019 which received no maintainer > > > response, however the package was not autoremoved from testing due to > > > aufs and aufs-tools being considered a "key packages" due to high popcon. > > > This popcon actually seems to be growing in both absolute and percentage > > > terms. I presume the high popcon is due to some deriviative (hence > > > debian-derivatives and debian-live in cc) using aufs in their live image > > > builds (as far as I can tell debian's own live images seem to use > > > overlayfs instead nowadays). > > >... > > > > It doesn't have to be a derivative, one webhoster who installs popcon by > > default is enough. > > It's very possible that it is the upstream Docker packaging that > accounts for the upward trend. The docker.io packages in the Debian > archive list aufs-tools as "Suggests", so they won't be pulled in by > default, but the upstream docker-ce packages distributed directly by > Docker still have them at Recommends. > > Docker no longer users aufs by default, though, having switched to > overlayfs some time ago. If it is wrong for them to pull in something they aren't using anymore, that's worth reporting. > I'm sure we could get them to drop the > Recommends if we're considering getting rid of it. Everything mentioned is only "it is possible that aufs might not be in Debian 11 when it releases mid-2021, unless someone fixes it in time for the release (which is likely)". Using it in buster is fine for any user even in the unlikely case it would not be in bullseye. It should be news to noone that popcon data is only very approximate for actual usage. It can give a hint regarding what is popular, but its data should be taken with a barrel of salt. > noah cu Adrian
Re: future of aufs in Debian.
On Tue, May 26, 2020 at 05:10:10PM +0300, Adrian Bunk wrote: > > Adrian filed a rc bug in November 2019 which received no maintainer > > response, however the package was not autoremoved from testing due to aufs > > and aufs-tools being considered a "key packages" due to high popcon. This > > popcon actually seems to be growing in both absolute and percentage terms. > > I presume the high popcon is due to some deriviative (hence > > debian-derivatives and debian-live in cc) using aufs in their live image > > builds (as far as I can tell debian's own live images seem to use overlayfs > > instead nowadays). > >... > > It doesn't have to be a derivative, one webhoster who installs popcon by > default is enough. It's very possible that it is the upstream Docker packaging that accounts for the upward trend. The docker.io packages in the Debian archive list aufs-tools as "Suggests", so they won't be pulled in by default, but the upstream docker-ce packages distributed directly by Docker still have them at Recommends. Docker no longer users aufs by default, though, having switched to overlayfs some time ago. I'm sure we could get them to drop the Recommends if we're considering getting rid of it. noah
Re: future of aufs in Debian.
On Tue, May 26, 2020 at 02:18:48PM +0100, peter green wrote: >... > Adrian filed a rc bug in November 2019 which received no maintainer response, > however the package was not autoremoved from testing due to aufs and > aufs-tools being considered a "key packages" due to high popcon. This popcon > actually seems to be growing in both absolute and percentage terms. I presume > the high popcon is due to some deriviative (hence debian-derivatives and > debian-live in cc) using aufs in their live image builds (as far as I can > tell debian's own live images seem to use overlayfs instead nowadays). >... It doesn't have to be a derivative, one webhoster who installs popcon by default is enough. phpmyadmin in stretch was a similar case, it went up to 10% popcon despite nothing in Debian installing it by default and no reverse dependencies (only a Suggests from a package with single-digit popcon). When the release team went through RC bugs key packages closer to the freeze phpmyadmin was removed from testing (and is not in buster). cu Adrian
