From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <rider@basealt.ru>
To: devel@lists.altlinux.org
References: <20200627055238.GA29429@gyle.altlinux.org>
 <a044fe08-99ed-693a-625c-96e0f8defa6f@basealt.ru>
 <20200627100322.GA17801@altlinux.org>
 <20200627131656.dea598cce8bcedff64df3075@altlinux.org>
From: Anton Farygin <rider@basealt.ru>
X-Opacus-Archived: none
Organization: BaseALT
Message-ID: <b184bbf7-0fdd-b5ae-a20c-db43826deb56@basealt.ru>
Date: Sat, 27 Jun 2020 14:31:36 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <20200627131656.dea598cce8bcedff64df3075@altlinux.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: ru
Subject: Re: [devel] beehive memory management
X-BeenThere: devel@lists.altlinux.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ALT Linux Team development discussions <devel@lists.altlinux.org>
List-Id: ALT Linux Team development discussions <devel.lists.altlinux.org>
List-Unsubscribe: <https://lists.altlinux.org/mailman/options/devel>,
 <mailto:devel-request@lists.altlinux.org?subject=unsubscribe>
List-Archive: <http://lists.altlinux.org/pipermail/devel>
List-Post: <mailto:devel@lists.altlinux.org>
List-Help: <mailto:devel-request@lists.altlinux.org?subject=help>
List-Subscribe: <https://lists.altlinux.org/mailman/listinfo/devel>,
 <mailto:devel-request@lists.altlinux.org?subject=subscribe>
X-List-Received-Date: Sat, 27 Jun 2020 11:31:37 -0000
Archived-At: <http://lore.altlinux.org/devel/b184bbf7-0fdd-b5ae-a20c-db43826deb56@basealt.ru/>
List-Archive: <http://lore.altlinux.org/devel/>
List-Post: <mailto:devel@altlinux.org>

On 27.06.2020 13:16, Andrey Savchenko wrote:
> On Sat, 27 Jun 2020 13:03:22 +0300 Dmitry V. Levin wrote:
>> On Sat, Jun 27, 2020 at 10:21:47AM +0300, Anton Farygin wrote:
>>> Я прошу ещё раз обратить внимание разработчиков beehive, что такое
>>> поведение неприемлемо.
>>>
>>> Данный пакет отлично собирается как в сборочнице так и локально. Удалять
>>> работающие пакеты из репозитория по причине того, что с ними не
>>> спавляется beehive крайне некорректно.
>> beehive и girar - это одна и та же сборочница.
А как она может быть одна и та-же, если у тебя физически оборудование 
разное ?
> Раз памяти хватает в girar, но не хватает в beehive — то уже не
> одна и та же.
>
Может быть, нам стоит внедрить ещё один тип сборочных зависимостей?


Например, BuildRequires: memory(ram) > 52
И в rpmbuild детектить объём доступной для сборки памяти и провайдить 
его как memory(ram) = 32 (для примера с beehive)

Сборка в этом случае даже не начнётся, ну и в принципе можно 
подстроиться на стороне (пере)сборочницы под требования пакета к ОЗУ.


Ну если zram не хочется использовать, конечно. Выделение половины ОЗУ 
под zram с типом сжатия LZO может увеличить общий объём ОЗУ на 25%.

https://www.kernel.org/doc/Documentation/blockdev/zram.txt