Сейчас слот, это такой способ версионирования, когда решение о делении на версии принимает мэйнтейнер, а не автор апстрима. Потому что мэйнтейнеру виднее, как надо. Потому что авторы неотзывчивые. В общем, сколько и каких слотов наделает мэйнтейнер, столько и будет стоять версий пакета.
Там ещё есть деление на субслоты и слоты, но это от двуличия. Мол, если ABI одинаковый, то мэйнтейнер делает один слот с разными субслотами для разных версий. Т.е. версия по видению мэйнтейнера размазывается на слот и субслот, а версия по видению девелопера отображается в номере слота.
На самом деле, в процессе потребления ПО участвуют и другие люди, такие, например, как пользователи. У пользователей могут быть свои соображения, отличные от соображений мэйнтейнеров. И может возникнуть желание установки нескольких экземпляров программы с одинаковыми SLOT/SUBSLOT, но при этом в разные места на диске.
Было бы совершенно чудесно, если бы portage позволял в переменную SLOT записывать строки с произвольным количеством разделителей, так же как строки с версиями ПО сейчас, и предоставлял функции типа ver_cut, только для SLOT (slot_cut?).
Пример использования №1: Пользователь хочет установить дебужную и релизную версию ПО одновременно. Что ему делать? Или только дебужную. Или только релизную.
Пример использования №2: Хочется иметь разные установки для разных сценариев использования. Например несколько профилей среды разработки, чтобы они использовали разные конфигурационные директории.
Пример использования №3: Оставлять одновременно несколько версий прикладной программы на случай, если в новой версии удалили какую-то функциональность (как это часто делают в Firefox)
Почему вместо переменной SLOT нельзя использовать любую другую переменную? Потому что только слоты можно добавить в DEPEND atom в файл /var/lib/portage/world. Там ещё есть лазейка - можно делать ограничение по репозиториям. Например сделать два репозитория - один для релизных билдов, другой для дебужных билдов. Но как-то это менее удобно, и не покрывает все сценарии использования.
Если бы я умел выделять версию SUBSLOT-а, можно было бы ещё подумать на тему user-patches с выбором вариантов на основе этого значения. Но в любом случае с сабслотами что-то не так - их внутрь ebuild-файла записывают или не записывают мэйнтейнеры. А надо что-то такое, чтобы оно записывалось в world-файл (пользователем) и было доступно внутри .ebuild.
Почему обязательно надо записывать в world-файл и нельзя обойтись переменными окружения, прописываемыми каждому пакету персонально? Потому что для установки нескольких экземпляров нужно, чтобы portage знал о каждом из установленных экземпляров приложения. Это работа именно пакетного менеджера - следить за установленными файлами.
Перемещено shell-script из development
