I still didn't decide about this one.

abrt people weren't against it. Developers like or dislike it based on their work-flow. I might be persuaded either way. 0 at the moment.

This Feature was approved at the 2012-06-18 meeting.

i contacted OLPC about this as they are very resource constrained the XO-1 has 1GiB of storage total for both the OS and user data. http://lists.laptop.org/pipermail/devel/2012-June/035485.html was the official response. ideally we can disable the minidebuginfo data being installed via a rpm macro like we have for docs or have it some other way so that it can be opted out of with a concious choice.

Do OLPC take packages from Fedora directly, or do they rebuild them all?

They take the i686 packages directly - it's why we have fairly conservative i686 optimization flags.

Stripping the minidebuginfo from the binaries is easy, Just run

strip -R .gnu_debugdata $binary_file

Also, note that the 43mb estimation in growt was for a full scale desktop install with a 8GB /usr with 1.8GB elf binaries, not a minimal OLPC install. It will be much less for OLPC.

OLPC ship a image with sugar and gnome, They have a full scale desktop in the image. it will not be much less for OLPC.

I don't understand. First you say that they are shipping with 1GB storage, then you're saying that they are not shipping much less than 8 GB of data. How does this work?

Obviously the final numbers can only be seen when things are done. But, as an estimate we can use some of the numbers from the feature page. In that installation /usr was 8GB, and contained 1.8GB (i.e. 22.5%) elf binaries. On average, elf binaries grew by 2.32% with the MiniDebugInfo.

An overestimate based on 1 GB /usr would then mean 1024MB0.2250.0232 ~= 5 MB.
Whether this is "much less" than 43MB is of course open for debate.

The oldest laptops (still supported and widely used) ship with 1GB storage, but with all data compressed (resulting in the actual space available being much higher). Our newer laptops ship with 4GB or 8GB of storage. And yes, we ship 2 full desktops and a whole host of applications.

The exact space increase number is perhaps not so significant. The concern is that the base system is growing. And its growing in a way that adds little or no value for our use case. (Not just limited to this particular feature request.) For us, and for any supplier of Fedora-based small systems in a similar situation, this is painful and causes us to make sacrifices of useful space and/or functionality in our software distribution.

Thats why we think there should be an option for it to be disabled cleanly and easily.

Do you think FESCo should vote on your use-case? It sounds reasonable that some spins will switch off this feature.

I believe OLPC creates OS images based on rpms and a set of scripts. Stripping all binaries of minidebuginfo should not need more than a few lines of post-process script as per comment 7.

What about the package signatures? Are they irrelevant for OLPC?

We do have a build system that runs some scripts after installing RPMs. We can do it this way (I'd appreciate not having to write that script myself though). However, at least to me, this does not seem like a good way of supporting small systems.

I'm not really sure how this relates to package signatures or if they are relevant to us. I also don't know exactly what a FESCo votes is but being a developer for one of the largest fedora installations in existence I of course think our situation should be considered carefully :)

Regarding package signatures: Rpm files can be signed with a gpg key. We sign all Fedora packages with a Fedora signing key. In turn, the rpms contain a hash of each file that's shipped inside of it so that someone using a system can tell if files from the package have been changed since installation. If part of the standard post-processing of the packages installed is stripping binaries of minidebuginfo then the hash will no longer match and you will no longer have a chain of trust back to Fedora. Besides that theoretical consideration I can think of the following end-user visible effects:

• rpm -V PACKAGE will report many files as having changed. Although technically true, what people running rpm -V are really interested in are "what things were changed locally, not in an expected manner from the OS vendor". So the automatic stripping results in less helpful information.
• Updates would have to download full rpms rather than deltarpms because they won't be able to reconstruct the to-be-installed rpms from the delta and the modified files that are on the system.

Whether these matter to you depends on how OLPC is distributed, updated, and the expectations of its users.

FESCo is the Fedora Engineering Steering Committee. They are the body that decides if features that have a global effect on the distribution should be approved, denied, or modified to work better/differently than originally presented.

Question: You talk about a build system that could strip the debug information. I could see several ways that would help and several ways it would not help. Is your buildsystem constructing an OLPC image? And once installed, the OLPC image won't be updated with actual rpm files but with new images? If so, you can probably successfully strip the files that have been installed into the image. If not, the debuginfo may still sneak onto OLPC systems whenever a raw rpm file is installed or upgraded.

Replying to [comment:17 toshio]:

• rpm -V PACKAGE will report many files as having changed. Although technically true, what people running rpm -V are really interested in are "what things were changed locally, not in an expected manner from the OS vendor". So the automatic stripping results in less helpful information.
• Updates would have to download full rpms rather than deltarpms because they won't be able to reconstruct the to-be-installed rpms from the delta and the modified files that are on the system.

Note that this is the case regardless of MiniDebuginfo if the image build process does any post-processing of package contents, such as removing unused locales, documentations or similar image pruning.

Thanks. "rpm -V" is not something we use on a day-to-day basis, but it is useful on occasion, as you can imagine.

We currently do strip locales and documentation, but we do it with regular RPM features, which means that "rpm -V" still works. If the suggested way of stripping minidebuginfo breaks that, it will be an unfortunate regression (but not the end of the world).

(Our build system does perform some other tweaks in other areas which "break" rpm -V, but only in a decreasing number of corners. Sounds like using a script as suggested to strip minidebuginfo would break that on large scale though.)

For the second case you mention, we already have the downside that yum updates override some actions done by the build system. For that reason amongst others, we don't encourage use of yum beyond the initial OS build, and we have our own update system. Some discussion: http://wiki.laptop.org/go/User:DanielDrake/Yum

Yes, our build system constructs the OLPC image, and once installed our updates are based on deltas between the current image and the next. So we wouldn't expect problems with upgrades, since we use the output of our build system for both new installs and updates.

The proposal for rejecting the feature did not get enough votes.

I do not think anyone wanted the feature rejected.

What is wanted is a way to be able to disable installing the minidebuginfo at package install time. I think the feature is great. but we should provide a mechanism in which it can be opted out of. its especially important for environments with limited space. please note that the deadline for having this feature in is this Friday 13th July, to give 2 weeks for things to settle down before we start the mass rebuild on the 30th July.

We discussed scripts for cleaning images of the debuginfo as part of image prep; splitting it out at the package level wasn't discussed, and (IMO) isn't practical.

Replying to [comment:22 notting]:

We discussed scripts for cleaning images of the debuginfo as part of image prep; splitting it out at the package level wasn't discussed, and (IMO) isn't practical.

I believe Matthew further suggested that he would be in favor of reviewing a proposal that was targeted at trimming a Fedora install down overall, which Minidebuginfo could be a part of. However singling it out when the rest of the software in Fedora continues to grow regardless seemed out of place.

Also note that FESCo cannot order to implement any new sub-feature to anyone. The kind of change you're talking about here would require substantial changes in rpm.

OK seems, its off the cards for now.

Extra info rather than just closing saying "The proposal for rejecting the feature did not get enough votes." when that is not what was asked to happen would not have gotten the ticket reopened.

POC example: to strip all the minidebuginfo from a directory, you would do:

{{{

!/bin/sh

find <directory> -type f | while read foo ; do
file $foo | grep -q "^$foo: ELF " &&
{ strip -R .gnu_debugdata $foo ; }
done
}}}