trimming down Fedora installed size

[Basil Mohamed Gohar]

On 04/10/2014 01:23 PM, Peter Oliver wrote:
> On 9 April 2014 22:10, Florian Festi <ffesti at redhat.com> wrote:
>>
>> On 04/09/2014 08:42 PM, Bill Nottingham wrote:
>>> Given the number of packages that ship localization, this seems like it
>>> would have a pretty dramatic effect on metadata size. Is this a concern?
>>
>> Meta data is a concern. But the major part of the meta data is file data
>> and change logs. Everything else is less than 10%. So doubling or even
>> tripling this part won't hurt.
> 
> What about performance?  I don't have any figures, but my feeling was
> that TeX seemed to update awfully slowly after it was split into many
> small packages.
> 

If package metadata is a problem, what if we split up the repositories
and allocate some, that we can deem to be, to some degree, optional, to
be for these less-than-mandatory packages.

So, for example, if the extra languages packages are put into their own
repository.  This would, of course, be unfair to the languages that are
not considered main, and this would likely heavily be biased towards
English given it probably has the widest coverage.

But what if manpages were in their own repository?

I guess my point is, can we spread the problem out across semi-optional
repositories and handle dependencies in a soft a way such that they'll
be installed if they are present [i.e., the repository(-ies) with the
given dependency(-ies) is/are present] but then the install continues
without a problem except maybe a gentle notice that there exist optional
dependencies so someone can choose to enable the associated repositories?

I don't know if this will introduce more problems than it solves, but
for the typical 1TB+ desktop user of Fedora, we can enable pretty-much
all of these "optional" repositories, and for the embedded and/or
minimal/micro installs, these optional repositories can be left unenabled.

I think this would require fewer changes to the dependency logic and RPM
itself than, say, a complicated set of flags and package labeling/tagging.

P.S.  Please forgive me if I use terms that might have specific meaning
to the packaging team (maybe tagging means something I don't intend in
that context, I'm using it generically).

-- 
Libre Video
http://librevideo.org