On Thu, Jul 31, 2008 at 11:10:29PM +0300, Igor Vlasenko wrote:
> Сейчас там на плоскости (S,s) вырезается первое приближение к гиперболе:
> |
> | |
> |  \ _
> |________
> 
> DELETE FROM t1 WHERE total <= 1048576;
> DELETE FROM t2 WHERE usrshare <= 1048576;
> отбрасываются пакеты с total < 1mb и с /usr/share/ < 1mb
> INSERT INTO t3 SELECT t1.pkgid, total, usrshare FROM t2 LEFT JOIN t1 ON t1.pkgid=t2.pkgid WHERE usrshare > 2097152 OR (usrshare > 1048576 AND usrshare/total > 0.5);
> затем выделяются пакеты с /usr/share/ > 2mb либо /usr/share/> 1mb и s/S >0.5.
> 
> В принципе можно сгладить, 
> только не понятно, стоит ли размениваться на пакеты S,s < 1mb.

У веса есть по крайней мере одно преимущество: если p=1, то это значит,
что либо все файлы в /usr/share, либо в пакете вообще нет файлов (это
зависит от того, как доопределить функцию).  В любом случае, такой пакет
очень просто сделать noarch (достаточно вписать "BuildArch: noarch",
ничего распиливать не надо).  (Правда, основной пакет нельзя сделать
noarch.)

Для остальных пакетов, которые нужно распиливать, отношение s/S будет,
скажем, в районе [0.5..1).  (Поясняю для остальных.)  Если размер пакета
близок к характерному размеру m, то p=s/S это и будет вес /usr/share части.
Для маленьких пакетов вес будет корректироваться в меньшую сторону: p<s/S,
чтобы не распиливать понапрасну маленькие пакеты.  А для больших пакетов
вес будет корректироваться в большую сторону: p>s/S, потому что даже
при, скажем, s/S=0.3 получается жирный лакомый кусок.  Короче,
непрерывная весовая функция позволяет легче определить, где искать кошелёк.

Правда, частный случай p=1 тоже легко отследить SQL запросом:
	... WHERE total = usrshare;