Bug#897277: Bug#474540: ext[23] should not be marked "essential"
On Tue, May 01, 2018 at 05:22:34PM +0200, Helmut Grohne wrote: > Hi Ted, > > I do want to ensure that this has gone through well ahead of the > transition freeze. Batching up such changes to the last moment makes > releasing buster on time harder. Even though the chance of breaking > something is low, it is not exactly equal zero. I want to have enough > time to fix things up in the unexpected case. Do you think there'll be a > minor release within May? That'd be fine from my point of view. The transition freeze is scheduled for January 12, 2019. That's a *long* time from now. This is why I'm puzlled by the urgency. It's likely we'll have a minor release in the next month --- so by early June at the latest; probably during May. Regards, - Ted
Bug#474540: ext[23] should not be marked "essential"
Hi Ted, Thank you for your quick reply. On Tue, May 01, 2018 at 10:16:40AM -0400, Theodore Y. Ts'o wrote: > I just didn't think it was worth it to do an upload just with the > priority change; my plan was to batch it with some other bug fixes in > the next e2fsprogs minor release. Is there a reason why you believe > it would be better to accelerate getting this pushed out to testing? I don't think there is a need to hurry just yet, but with my proposed backup plan it would have still been at least four weeks until the change would hit testing. I do want to ensure that this has gone through well ahead of the transition freeze. Batching up such changes to the last moment makes releasing buster on time harder. Even though the chance of breaking something is low, it is not exactly equal zero. I want to have enough time to fix things up in the unexpected case. Do you think there'll be a minor release within May? That'd be fine from my point of view. Helmut
Bug#897277: [ty...@mit.edu: Re: Bug#474540: ext[23] should not be marked "essential"]
--- Begin Message --- On Tue, May 01, 2018 at 10:29:19AM +0200, Helmut Grohne wrote: > > On Sun, Apr 15, 2018 at 07:15:45PM +0200, Helmut Grohne wrote: > > Thus I ask Ted to drop the Essential flag now. I am attaching a patch > > that replaces Essential: yes with XB-Important: yes. > > It seems that you presently lack the time to implement this change. The > bug log indicates that merely replacing Essential with XB-Important is > uncontroversial (messages #92 and #102). Thus I propose NMUing e2fsprogs > with the patch I sent earlier. Unless I hear from you, I'll move forward > with a delayed NMU in a week. I just didn't think it was worth it to do an upload just with the priority change; my plan was to batch it with some other bug fixes in the next e2fsprogs minor release. Is there a reason why you believe it would be better to accelerate getting this pushed out to testing? Cheers, - Ted --- End Message ---
Bug#474540: ext[23] should not be marked "essential"
On Tue, May 01, 2018 at 10:29:19AM +0200, Helmut Grohne wrote: > > On Sun, Apr 15, 2018 at 07:15:45PM +0200, Helmut Grohne wrote: > > Thus I ask Ted to drop the Essential flag now. I am attaching a patch > > that replaces Essential: yes with XB-Important: yes. > > It seems that you presently lack the time to implement this change. The > bug log indicates that merely replacing Essential with XB-Important is > uncontroversial (messages #92 and #102). Thus I propose NMUing e2fsprogs > with the patch I sent earlier. Unless I hear from you, I'll move forward > with a delayed NMU in a week. I just didn't think it was worth it to do an upload just with the priority change; my plan was to batch it with some other bug fixes in the next e2fsprogs minor release. Is there a reason why you believe it would be better to accelerate getting this pushed out to testing? Cheers, - Ted
Bug#474540: ext[23] should not be marked "essential"
Control: clone -1 -2 Control: retitle -2 decrease e2fsprogs' Priority: required Control: tags -2 - patch Control: block -2 by -1 Hi Ted, On Sun, Apr 15, 2018 at 07:15:45PM +0200, Helmut Grohne wrote: > Thus I ask Ted to drop the Essential flag now. I am attaching a patch > that replaces Essential: yes with XB-Important: yes. It seems that you presently lack the time to implement this change. The bug log indicates that merely replacing Essential with XB-Important is uncontroversial (messages #92 and #102). Thus I propose NMUing e2fsprogs with the patch I sent earlier. Unless I hear from you, I'll move forward with a delayed NMU in a week. I'm also splitting this bug in accordance with the discussion. The new bug -2 is about changing the Priority field and I don't see it being fixed soon, because I don't see consensus here and I don't intend to work on this part myself. Possibly we should tag it wontfix or moreinfo for the time being. Helmut
Bug#474540: ext[23] should not be marked "essential"
Control: tags -1 + patch
On Mon, Aug 21, 2017 at 08:42:16AM -0400, Theodore Ts'o wrote:
> On Mon, Aug 21, 2017 at 09:34:20AM +0200, Andreas Henriksson wrote:
> > Step 1: Essential: yes -> Important: yes
You know I've picked up the work to make this happen. To that end, I
inspected the archive and figured which packages need dependencies on
e2fsprogs and filed bugs. Those bugs can be viewed at
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=nonessentiale2fsprogs;users=helm...@debian.org
and at the time of this writing 100 / 132 are fixed. Of the remaining 32
bugs, 11 are minor (i.e. not adding a dependency but
recommends/suggests) and 7 are pending. Thus our upper bound for missing
dependencies is 21 packages at present.
Thus I think it is time to move forward.
> > Step 2: Priority: required -> Priority: important
> I think we're converging. I'm not entirely convinced about Step 2 for
> buster. I am just concerned it's going to cause more disruption than
> might be first expected --- and finding the possible gotchas is going
> to be hard until we do a stable release of Buster.
I think we agree that we don't agree on step 2 at the moment. I thus ask
for removing step 2 from the scope of this bug (the and the bug title
doesn't say anything about priority either). If someone wants to pursue
step 2, please file (or clone) a new bug.
Thus I ask Ted to drop the Essential flag now. I am attaching a patch
that replaces Essential: yes with XB-Important: yes.
The implications will be:
* debootstrap will continue to install e2fsprogs in all variants (due
to priority). Other bootstrap tools may do without e2fsprogs. The
latter aspect is the one I'm after.
* apt and others will refuse removing e2fsprogs (due to XB-Important)
* Packages that use something from e2fsprogs without declaring a
dependency will be eligible for a bug of severity serious.
This change really has quite low chance of negatively impacting
anything. Once Essential: yes is dropped, I'll bump the severity of the
remaining 21 bugs to serious.
Helmut
diff --minimal -Nru e2fsprogs-1.44.1/debian/changelog
e2fsprogs-1.44.1/debian/changelog
--- e2fsprogs-1.44.1/debian/changelog 2018-04-10 17:04:36.0 +0200
+++ e2fsprogs-1.44.1/debian/changelog 2018-04-15 19:00:01.0 +0200
@@ -1,3 +1,11 @@
+e2fsprogs (1.44.1-2.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Demote e2fsprogs from Essential: yes to XB-Important: yes. (Closes:
+#474540)
+
+ -- Helmut Grohne Sun, 15 Apr 2018 19:00:01 +0200
+
e2fsprogs (1.44.1-2) unstable; urgency=medium
* Fix e2image handling of e2i files on big endian systems
diff --minimal -Nru e2fsprogs-1.44.1/debian/control
e2fsprogs-1.44.1/debian/control
--- e2fsprogs-1.44.1/debian/control 2018-04-10 17:04:36.0 +0200
+++ e2fsprogs-1.44.1/debian/control 2018-04-15 18:59:55.0 +0200
@@ -187,7 +187,7 @@
libraries.
Package: e2fsprogs
-Essential: yes
+XB-Imporant: yes
Pre-Depends: ${shlibs:Depends}, ${misc:Depends}, libblkid1, libuuid1
Multi-Arch: foreign
Suggests: gpart, parted, fuse2fs, e2fsck-static
Bug#474540: ext[23] should not be marked "essential"
On Mon, Aug 21, 2017 at 08:42:16AM -0400, Theodore Ts'o wrote: [...] > So what I am currently thinking might be a viable first step is to > split out the translations for e2fsprogs and transition from > Essential: yes to Essential: no, since there is no controversy over > that step. We can then decide whether or not it's worthwhile to try > to make the Priority: required -> Priority -> important transition > during Buster or not. > > Sounds fair? Yes! Thanks for the quick feedback and sorry for any confusion. Looking forward to see your changes uploaded in hopefully not too distant future. If you don't, I'll likely soon start the debian-devel discussion about more minbase packages splitting their locales out and see what people think about it and see if we can attract the attention of atleast the top savings package maintainers. Regards, Andreas Henriksson
Bug#474540: ext[23] should not be marked "essential"
On Mon, Aug 21, 2017 at 09:34:20AM +0200, Andreas Henriksson wrote: > Your 1) and 2) is what I initially called "step 1" and "step 2" to try > to indicate they are to separate distincts steps. > > Step 1: Essential: yes -> Important: yes > Step 2: Priority: required -> Priority: important > > > > > We can make the first change without the second. The first allows us > > packages to declare dependencies. The second shrinks the minbase > > size. And that's why I was asking the question what problem exactly > > that we being solved here. Since if it's just the dependency issue, > > we can change Essential to No. > > I'm perfectly happy if we just do step 1 for buster (upcoming release). > > I think it would be nice to atleast keep the option open for discussion > of doing also step 2 later (in Bullseye?, release after Buster -- about > 4-5 years from now), if you think doing it for buster is too agressive. > > The main reason for doing 'step 2' would be to make 'minbase' a "slim" > version of debian "out of the box" (without tweaks needed. Basically > same motivation as for splitting out the locales of minbase packages.) I think we're converging. I'm not entirely convinced about Step 2 for buster. I am just concerned it's going to cause more disruption than might be first expected --- and finding the possible gotchas is going to be hard until we do a stable release of Buster. That being said, it's going to be true for no matter when we do it, and it's early in the Buster cycle, so I do understand the "what the heck, let's just do it now" argument. I'm just not 100% sure I find it super-compelling. However, splitting out the locales for the minbase will save *substantially* more space for a "slim" version of Debian, and we can **definitely** do it now, for the Buster release. So what I am currently thinking might be a viable first step is to split out the translations for e2fsprogs and transition from Essential: yes to Essential: no, since there is no controversy over that step. We can then decide whether or not it's worthwhile to try to make the Priority: required -> Priority -> important transition during Buster or not. Sounds fair? - Ted
Bug#474540: ext[23] should not be marked "essential"
Hi, On Sun, Aug 20, 2017 at 05:40:20PM -0400, Theodore Ts'o wrote: [...] > The normal Debian Docker images uses --variant=minbase. So changing > e2fsprogs from Priority: required to Priority: important **will** > change the Docker image. Ref: > > https://github.com/moby/moby/blob/master/contrib/mkimage.sh I thought tianon did the official images. Just goes to show how out of the loop I am with docker these days. I'd recommend they add a '--include=mount,fdisk,e2fsprogs' to their debootstrap command for the future (in their non-slim version(s)?) if they want to be sure to preserve the tools in their base image for the future. [...] > > I think you're entangling two different changes: > > 1) Essential: yes->no > 2) Priority: required->important > > No? Yes. Your 1) and 2) is what I initially called "step 1" and "step 2" to try to indicate they are to separate distincts steps. Step 1: Essential: yes -> Important: yes Step 2: Priority: required -> Priority: important > > We can make the first change without the second. The first allows us > packages to declare dependencies. The second shrinks the minbase > size. And that's why I was asking the question what problem exactly > that we being solved here. Since if it's just the dependency issue, > we can change Essential to No. I'm perfectly happy if we just do step 1 for buster (upcoming release). I think it would be nice to atleast keep the option open for discussion of doing also step 2 later (in Bullseye?, release after Buster -- about 4-5 years from now), if you think doing it for buster is too agressive. The main reason for doing 'step 2' would be to make 'minbase' a "slim" version of debian "out of the box" (without tweaks needed. Basically same motivation as for splitting out the locales of minbase packages.) Regards, Andreas Henriksson
Bug#474540: ext[23] should not be marked "essential"
On Sun, Aug 20, 2017 at 03:08:32PM +0200, Andreas Henriksson wrote: > > > step 1: Switch from Essential: yes to Important: yes > > > > > > This will not be much of a change in practise. Higher level tools > > > like apt etc will still not want to uninstall the package, but > > > you can now uninstall it using dpkg without getting the > > > 'are you really sure you know what you're doing' question. > > > I'd say the most important difference is that according to > > > debian-policy (which doesn't know anything about Important: yes) > > > the package is now no longer Essential and thus other packages > > > are now allowed to add dependencies where needed. > > > > I think you mean "don't know anything about Required: yes" above, but > > No, AFAIK there's no such this as "Required: yes". Only > "Essential: yes" and (the newish) "Important: yes". > > I guess you're mixing this up with the "Priority: ..." field because > of the somewhat confusing naming. Sorry, I meant to type "Priority: Required". We can do Essential: Yes / Priority: Required and I think that's safe. It's dropping Priority: down to Important is where things get interesting > > > > It's not just the builders; it will also be the Debian Docker image. > > I haven't checked, but I would assume the (normal) debian docker images > are built from a normal default debootstrap, which would include > "Priority: important" packages and thus e2fsprogs would still be there. The normal Debian Docker images uses --variant=minbase. So changing e2fsprogs from Priority: required to Priority: important **will** change the Docker image. Ref: https://github.com/moby/moby/blob/master/contrib/mkimage.sh > By making a package Essential: yes you (via debian-policy) forbit > packages to declare a dependency and thus the relationships between > packages can not easily be tracked. At the same time deinstalling an > Essential: yes package is just one additional step (answering one > additional confirmation question). I think you're entangling two different changes: 1) Essential: yes->no 2) Priority: required->important No? We can make the first change without the second. The first allows us packages to declare dependencies. The second shrinks the minbase size. And that's why I was asking the question what problem exactly that we being solved here. Since if it's just the dependency issue, we can change Essential to No. - Ted
Bug#474540: ext[23] should not be marked "essential"
Hello Theodore Ts'o, This mail dedicated to the potential confusion about Essentialness and Priority. On Sat, Aug 19, 2017 at 06:51:11PM -0400, Theodore Ts'o wrote: > On Fri, Aug 18, 2017 at 01:21:57PM +0200, Andreas Henriksson wrote: > > I would like to breath some life into this bug report. I've been > > collecting information/brainstorming-ideas about minimal debian > > installation (debootstrap --variant=minbase) on > > https://wiki.debian.org/BusterPriorityRequalification > > > > The e2fsprogs was one of the packages that where questioned if > > it really needs to be Essential: yes / Priority: required. > > It is also one of the largest packages in the minbase set. > > There is one thing I can very quickly and easily do to to improve the > minbase set. We can significantly reduce the size of e2fsprogs (by > more half) by simply moving all of its locale files to a new package, > e2fsprogs-l10n. That shrinks installed size of e2fsprogs from 2825k > to 1330k. > > > step 1: Switch from Essential: yes to Important: yes > > > > This will not be much of a change in practise. Higher level tools > > like apt etc will still not want to uninstall the package, but > > you can now uninstall it using dpkg without getting the > > 'are you really sure you know what you're doing' question. > > I'd say the most important difference is that according to > > debian-policy (which doesn't know anything about Important: yes) > > the package is now no longer Essential and thus other packages > > are now allowed to add dependencies where needed. > > I think you mean "don't know anything about Required: yes" above, but No, AFAIK there's no such this as "Required: yes". Only "Essential: yes" and (the newish) "Important: yes". I guess you're mixing this up with the "Priority: ..." field because of the somewhat confusing naming. > yes, it seems largely safe to do this. Given that Debian policy > states that packages should not be made "Essential" without a > discussion on debian-devel, I'd probably want to also raise this as a > proposal on debian-devel before changing "Essential: yes" to > "Essential: no". Not sure the reverse of making something Essential automatically applies but sure a debian-devel discussion might be useful, if not only to increase actual debian development related mail on the list. (Fwiw, I recently sent out a discussion related to src:util-linux and lowering the Essential-ness of the packages which resulted in very little useful discussion. Doesn't seem too many people in genreral are interested in the core stuff.) > > > step 2: Dowgrade from Priority: required to Priority: important > > > > This means e2fsprogs will still be part of every normal install, > > just not part of 'debootstrap --variant=minbase' (e.g. buildd chroots > > and other specialized systems). > > Pitfalls with this change would be that every package who needs > > something from e2fsprogs (eg. lsattr, chattr) during build phase > > must have a build-dependency on e2fsprogs or they will FTBFS. > > Given we're still early in the Buster development cycle, I would > > personally think this change is pretty safe to do now but depends > > on how much fuzz you're willing to stir up. I'd like to offer > > my help in fixing this (by filing bug reports and doing non-maintainer > > uploads where needed). > > It's not just the builders; it will also be the Debian Docker image. I haven't checked, but I would assume the (normal) debian docker images are built from a normal default debootstrap, which would include "Priority: important" packages and thus e2fsprogs would still be there. I would expect only the 'slim' variant to be built from --variant=minbase and anyone using slim would ofcourse expect that it contains less software than the normal variant. > And while it might be fair to say that containers won't need "mount", > it's somewhat more likely that there might be build containers that > will assume the existence of mke2fs. > > I'm not sure how to address that, since at least with debian packages > it's a relatively closed universe so we would discover problems as the > reproducible build system tried to rebuild various packages, for > example. But I could imagine so Docker container designed to rebuild > cyanogen or AOSP (for example) that would be assuming e2fsprogs to be > present, and would blow up as a result. Apart from my above comment, the best we can do is to document the change in a high-level understandable way in the Release Notes. While not everyone reads the release notes, hopefully atleast the people making downstream redistributions does Then they can relay the information to their users in their most suitable way. > > This is one of the reasons why, if the goal is to shrink the size of > minbase shrinking e2fsprogs by removing all of the locale files is > probably the biggest bang for our buck that we can do right away, and > is guaranteed to be 100% safe --- since there won't be any users of >
Bug#474540: ext[23] should not be marked "essential"
Hello, On Sat, Aug 19, 2017 at 09:15:24PM -0400, Theodore Ts'o wrote: > On Sun, Aug 20, 2017 at 01:22:52AM +0200, Marco d'Itri wrote: > > On Aug 20, Theodore Ts'o wrote: > > > > > By the way, I was just taking a quick look, and e2fsprogs isn't the > > > only offender in this regard. Out of a 201 MB i386 minbase chroot, 33 > > > MB, or over 16% can be found in /usr/share/locale. The next largest > > > hierarchies under /usr/share are /usr/share/doc, at 9.4 MB, and > > > /usr/share/man, at 6.1 MB. > > > > > > So if the goal is to shrink minbase, that might be a really good place > > > to start. Packages that might be good initial first targets would > > > probably be coreutils, dpkg, and gnupg. > > > > I am not persuaded that we should split a significant number of packages > > (how many? Where do you draw the line?) this way: we already have a tool > > to solve this in a general way, i.e. localepurge. > > From the localepurge package description: > >This tool is a hack which is *not* integrated with the system's >package management system and therefore is not for the faint of heart. >Its interference can provoke strange, but usually harmless, behavior in >programs related to apt/dpkg, such as dpkg-repack, reportbug, etc. > > In either case, it seems unlikely people would be happy doing using > either localepurge or dpkg --path-exclude for official Docker images. It's already being used to get rid of some/most /usr/share/doc content in the 'slim' variant of the "official" Debian images. https://github.com/tianon/docker-brew-debian/issues/48 > Splitting out the locale files is going to be much easier to support > than trying to hammer localremove into debootstrap. > > Furthermore, it's not a significant number of packages, simply because > there aren't a huge number of packages in minbase that have locale > files to begin with, and only a handful of those have significantly > sized locale files. While I see localepurge as the general solution, I agree your suggestion of splitting locales out (and shipping them in separate 'Priority: important' packages thus not being included in 'minbase') has some value simply by improving the 'out of the box' experience. Maybe it's worth discussing it to see if there's enough consensus to implement it for all/biggest minbase packages and where we draw the line if we only do the top ones. An example of where this is already implemented is util-linux-locales (but it has Priority: optional, not sure why it's like that). I've your information as an item (and appendix with your calculations table) on https://wiki.debian.org/BusterPriorityRequalification At the same time I also want to point out that space saving is just one small detail this. Shrinking the number of 'Essential: yes' packages has several other benefits, including simplifying bootstrapping, allowing dependency tracking... Splitting locales should be just considered an additional parallell effort to shrinking Essential. Regards, Andreas Henriksson
Bug#474540: ext[23] should not be marked "essential"
On Sun, Aug 20, 2017 at 01:22:52AM +0200, Marco d'Itri wrote: > On Aug 20, Theodore Ts'o wrote: > > > By the way, I was just taking a quick look, and e2fsprogs isn't the > > only offender in this regard. Out of a 201 MB i386 minbase chroot, 33 > > MB, or over 16% can be found in /usr/share/locale. The next largest > > hierarchies under /usr/share are /usr/share/doc, at 9.4 MB, and > > /usr/share/man, at 6.1 MB. > > > > So if the goal is to shrink minbase, that might be a really good place > > to start. Packages that might be good initial first targets would > > probably be coreutils, dpkg, and gnupg. > > I am not persuaded that we should split a significant number of packages > (how many? Where do you draw the line?) this way: we already have a tool > to solve this in a general way, i.e. localepurge. >From the localepurge package description: This tool is a hack which is *not* integrated with the system's package management system and therefore is not for the faint of heart. Its interference can provoke strange, but usually harmless, behavior in programs related to apt/dpkg, such as dpkg-repack, reportbug, etc. In either case, it seems unlikely people would be happy doing using either localepurge or dpkg --path-exclude for official Docker images. Splitting out the locale files is going to be much easier to support than trying to hammer localremove into debootstrap. Furthermore, it's not a significant number of packages, simply because there aren't a huge number of packages in minbase that have locale files to begin with, and only a handful of those have significantly sized locale files. Here's the breakdown of all of the packages with locale files in the minbase set in Debian Jessie, the savings (in kilobytes of installed size) if we were to split out their locale files, and the cummulative savings if we split the top N packages. Package Savings Cummulative Savings Percentage coreutils 8052 805224.91 dpkg46201267239.20 bash37441641650.78 gnupg 34241984061.37 e2fsprogs 17762161666.86 tar 16802329672.06 shadow 16322492877.11 apt 15282645681.84 libapt-pkg4.12 10522750885.09 Linux-PAM 796 2830487.55 findutils 756 2906089.89 grep636 2969691.86 diffutils 620 3031693.78 debconf 596 3091295.62 adduser 444 3135696.99 sed 428 3178498.32 libgpg-error388 3217299.52 systemd 84 3225699.78 acl 72 32328 100.00 I wouldn't call 12 packages a "significant number", and that would get us over 90% of the 32 megabyte savings. Splitting the top six would get us 72% of the savings. And with *zero* chance of compatibility problems. In addition, most of these packages, including the the top three packages on the above list are ones that we could **never** remove from the essential=yes / priority=required set. Finally, splitting out the locale files for coreutils alone would net almost three times the savings of completely removing e2fsprogs (2809k in Jessie) from the minbase set. If you think it's worth it to work on removing e2fsprogs from minbase, why not split out at least coreutils, dpkg, bash, and gnupg? It will be less work, and will result in more disk space saved. - Ted
Bug#474540: ext[23] should not be marked "essential"
On Aug 20, Theodore Ts'o wrote: > By the way, I was just taking a quick look, and e2fsprogs isn't the > only offender in this regard. Out of a 201 MB i386 minbase chroot, 33 > MB, or over 16% can be found in /usr/share/locale. The next largest > hierarchies under /usr/share are /usr/share/doc, at 9.4 MB, and > /usr/share/man, at 6.1 MB. > > So if the goal is to shrink minbase, that might be a really good place > to start. Packages that might be good initial first targets would > probably be coreutils, dpkg, and gnupg. I am not persuaded that we should split a significant number of packages (how many? Where do you draw the line?) this way: we already have a tool to solve this in a general way, i.e. localepurge. I strongly support Andreas' goal, and I think that demoting e2fsprogs would not cause significant compatibility problems since it would happen only for a new release when other things usually need to be tweaked anyway. -- ciao, Marco signature.asc Description: PGP signature
Bug#474540: ext[23] should not be marked "essential"
On Fri, Aug 18, 2017 at 01:21:57PM +0200, Andreas Henriksson wrote: > I would like to breath some life into this bug report. I've been > collecting information/brainstorming-ideas about minimal debian > installation (debootstrap --variant=minbase) on > https://wiki.debian.org/BusterPriorityRequalification > > The e2fsprogs was one of the packages that where questioned if > it really needs to be Essential: yes / Priority: required. > It is also one of the largest packages in the minbase set. There is one thing I can very quickly and easily do to to improve the minbase set. We can significantly reduce the size of e2fsprogs (by more half) by simply moving all of its locale files to a new package, e2fsprogs-l10n. That shrinks installed size of e2fsprogs from 2825k to 1330k. > step 1: Switch from Essential: yes to Important: yes > > This will not be much of a change in practise. Higher level tools > like apt etc will still not want to uninstall the package, but > you can now uninstall it using dpkg without getting the > 'are you really sure you know what you're doing' question. > I'd say the most important difference is that according to > debian-policy (which doesn't know anything about Important: yes) > the package is now no longer Essential and thus other packages > are now allowed to add dependencies where needed. I think you mean "don't know anything about Required: yes" above, but yes, it seems largely safe to do this. Given that Debian policy states that packages should not be made "Essential" without a discussion on debian-devel, I'd probably want to also raise this as a proposal on debian-devel before changing "Essential: yes" to "Essential: no". > step 2: Dowgrade from Priority: required to Priority: important > > This means e2fsprogs will still be part of every normal install, > just not part of 'debootstrap --variant=minbase' (e.g. buildd chroots > and other specialized systems). > Pitfalls with this change would be that every package who needs > something from e2fsprogs (eg. lsattr, chattr) during build phase > must have a build-dependency on e2fsprogs or they will FTBFS. > Given we're still early in the Buster development cycle, I would > personally think this change is pretty safe to do now but depends > on how much fuzz you're willing to stir up. I'd like to offer > my help in fixing this (by filing bug reports and doing non-maintainer > uploads where needed). It's not just the builders; it will also be the Debian Docker image. And while it might be fair to say that containers won't need "mount", it's somewhat more likely that there might be build containers that will assume the existence of mke2fs. I'm not sure how to address that, since at least with debian packages it's a relatively closed universe so we would discover problems as the reproducible build system tried to rebuild various packages, for example. But I could imagine so Docker container designed to rebuild cyanogen or AOSP (for example) that would be assuming e2fsprogs to be present, and would blow up as a result. This is one of the reasons why, if the goal is to shrink the size of minbase shrinking e2fsprogs by removing all of the locale files is probably the biggest bang for our buck that we can do right away, and is guaranteed to be 100% safe --- since there won't be any users of the e2fsprogs locale files except for e2fsprogs itself, and most of the time they aren't used at all (at least in the English speaking world :-). (And of course, in build chroots for reproducible-build reasons.) By the way, the other program that other packages may be using is logsave(8) -- the sysvinit and initramfs-tools packages use logsave at the very least. > Bonus step: consider chattr/lsattr move to util-linux? > > As I understand it, chattr and lsattr used to be ext-specific. Nowadays > more filesystems seems to have implemented the same interface and thus > made the tools useful in a broader scope. Yeah, mumble. I'd have to think about that. We're still adding new ext4-specific flags to chattr and lsattr, so I'm less enthusiastic about moving them. The other libraries/packages that were moved to util-linux where the uuid and blkid libraries (and associated userspace utilities). Those were largely no longer changing in any ext4-specific way, so it was a lot easier to be willing to move it to util-linux. The logsave binary falls in that category, and so I would have no objections to moving logsave to util-linux. It's stayed in e2fsprogs mostly out of inertia. Regards, - Ted
Bug#474540: ext[23] should not be marked "essential"
On Sat, Aug 19, 2017 at 06:51:11PM -0400, Theodore Ts'o wrote: > > There is one thing I can very quickly and easily do to to improve the > minbase set. We can significantly reduce the size of e2fsprogs (by > more half) by simply moving all of its locale files to a new package, > e2fsprogs-l10n. That shrinks installed size of e2fsprogs from 2825k > to 1330k. By the way, I was just taking a quick look, and e2fsprogs isn't the only offender in this regard. Out of a 201 MB i386 minbase chroot, 33 MB, or over 16% can be found in /usr/share/locale. The next largest hierarchies under /usr/share are /usr/share/doc, at 9.4 MB, and /usr/share/man, at 6.1 MB. So if the goal is to shrink minbase, that might be a really good place to start. Packages that might be good initial first targets would probably be coreutils, dpkg, and gnupg. Cheers, - Ted
Bug#474540: ext[23] should not be marked "essential"
Hello! I would like to breath some life into this bug report. I've been collecting information/brainstorming-ideas about minimal debian installation (debootstrap --variant=minbase) on https://wiki.debian.org/BusterPriorityRequalification The e2fsprogs was one of the packages that where questioned if it really needs to be Essential: yes / Priority: required. It is also one of the largest packages in the minbase set. While making things non-essential is quite hard because there's no obvious path to take, as already has been discussed in this bug report I'd like to suggest starting with what I just did to the (src:util-linux) mount package. step 1: Switch from Essential: yes to Important: yes This will not be much of a change in practise. Higher level tools like apt etc will still not want to uninstall the package, but you can now uninstall it using dpkg without getting the 'are you really sure you know what you're doing' question. I'd say the most important difference is that according to debian-policy (which doesn't know anything about Important: yes) the package is now no longer Essential and thus other packages are now allowed to add dependencies where needed. step 2: Dowgrade from Priority: required to Priority: important This means e2fsprogs will still be part of every normal install, just not part of 'debootstrap --variant=minbase' (e.g. buildd chroots and other specialized systems). Pitfalls with this change would be that every package who needs something from e2fsprogs (eg. lsattr, chattr) during build phase must have a build-dependency on e2fsprogs or they will FTBFS. Given we're still early in the Buster development cycle, I would personally think this change is pretty safe to do now but depends on how much fuzz you're willing to stir up. I'd like to offer my help in fixing this (by filing bug reports and doing non-maintainer uploads where needed). Bonus step: consider chattr/lsattr move to util-linux? As I understand it, chattr and lsattr used to be ext-specific. Nowadays more filesystems seems to have implemented the same interface and thus made the tools useful in a broader scope. If I'm not mistaken in the past some tools that has been developed as e2fsprogs utilities has moved to util-linux once they've become generic enough. The chattr and lsattr tools seems to be widely enough used in debian (codesearch.debian.net says 133 packages match chattr for example), that it might be useful to keep these two tools in the Essential set while moving the rest out. Not sure how much work it would be, but maybe the chattr and lsattr implementations could move over to util-linux (upstream) and after we can transition in Debian to ship these utils in the 'util-linux' binary package? This is mostly just a thought on how 'step 2' could be simplified. I'm very keen on seeing this move forward, so I'd like to hear your opinion on it. I'm also willing to help out where needed so please speak up if you have any work in mind that needs to be done. Regards, Andreas Henriksson
Bug#474540: ext[23] should not be marked "essential"
Package: e2fsprogs Version: 1.40.8-2 Severity: wishlist Looking at the large number of different file systems for Linux I wonder whether it would be possible to split e2fsprogs to keep the "essential" part separate from the file system specific part? I am running Debian without ext[23] filesystems for many years without any problems, so I would like to get rid of the tools that are "ext2-only". Regards Harri -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
