Florian Festi wrote: > I think the technical reasons and arguments have been all already > mentioned. So there are only a few minor remarks: > > Although I compiled some quite comprehensive lists of packages to be > changed/split to noarch it is not intended to blindly switch over all of > them. If you feel uncomfortable with one or several of your packages > being changed just leave them as they are. As a general rule of thumb: > If there are doubt whether it is a good idea to change a package leave > it alone. > > Toshio Kuratomi wrote: >> But building things as arch specific subpackages when they could be >> noarch is a feature that costs us what exactly? A bit of space? > > I think you underestimate the amount of noarch data in the distribution. > From approximately 40 GB of content (in files) about 29 GB are not arch > dependent while there are only 10.7GB of binaries and libraries. Even if > you assume that the noarch content is compressed twice as good as the > binaries the larger part of the distribution is still packaged noarch > content. Right now about half of the noarch content already is in > regular noarch packages. > > So even if we only save about 10GB of mirror space for one release for > now it sums up over time for updates and new releases. I even expect > that the percentage of noarch content is increasing in the future and > every new supported architecture will automatically gain from the work > done (if there going to be any). > Ah... but I'm not talking about turning noarch subpackages off. I'm talking about talking about increasing the level of checking that happens before a noarch subpackage is allowed. So how much of the content that you list in 29GB saved is %doc? How much is scripting languages that we could decide to select on via path and filename extension? How much of those are headers that do not have timestamps or build hosts embedded into them? We have the capability to noarh subpackage all of those if we turn on an rpmdiff that does md5sum checking but can exclude those properties. I think we'll see substantial savings from allowing through things that meet a heuristic while still placing the burden of checking this onto an automated tool instead of a human. -Toshio
Attachment:
signature.asc
Description: OpenPGP digital signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
