Re: Noarch subpackage problem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux