История изменений
Исправление Pinkbyte, (текущая версия) :
Еще раз - если у тебя есть предложения как работать с опциональными зависимостями так, чтобы не разгребать потом ад с --depclean - добро пожаловать в мэйллист, мы готовы тебя выслушать
Только не забудь случаи вида «пакет А задетектил установленный, но не прописанный по зависимости, опциональный пакет B. Далее пакет C проверяет(тоже опциональную) поддержку B в пакете A и сюрприз, находит её. Потом пользователь выполняет emerge --depclean, пакет B отправляется в /dev/null и пакет C начинает вести себя вообще по-другому, а то и глючить». Продолжи эту линию неучтенных зависимостей, помножь это на то, что чем глубже отсутствующий пакет, тем обычно невнятнее сообщение об ошибке и на выходе ты получишь ад.
Если ты думаешь, что такое встречается очень редко - у меня для тебя плохие новости.
Вынос такого в USE-флаги - тоже не панацея, если нельзя флагами принудительно объяснить пакету A что поддержку B делать не нужно(даже если пакет B установлен). Для пакетов, проверяющих наличие поддержки в рантайме с текущими возможностями USE-флагов это сделать просто НЕЛЬЗЯ.
Вообще мне кажется что я уже по-третьему кругу разжевываю тебе чем чревато такая чехарда с зависимостями. Если тебя не устраивает наличие конкретного в системе - у тебя всегда к услугам package.provided. Тут как с user patches - есть поддерживаемая разработчиками конфигурация, есть неподдеживаемая. Это не значит что пользователю нельзя накладывать патчи, просто первым делать попросят пересобрать пакет без них, дабы убедиться что это не они - проблема.
Пока что опциональные зависимости, которые никак не ложатся на парадигму USE-флагов - это неподдерживаемая конфигурация.
Исправление Pinkbyte, :
Еще раз - если у тебя есть предложения как работать с опциональными зависимостями так, чтобы не разгребать потом ад с --depclean - добро пожаловать в мэйллист, мы готовы тебя выслушать
Только не забудь случаи вида «пакет А задетектил установленный, но не прописанный по зависимости, опциональный пакет B. Далее пакет C проверяет(тоже опциональную) поддержку B в пакете A и сюрприз, находит её. Потом пользователь выполняет emerge --depclean, пакет B отправляется в /dev/null и пакет C начинает вести себя вообще по-другому, а то и глючить». Продолжи эту линию неучтенных зависимостей, помножь это на то, что чем глубже отсутствующий пакет, тем обычно невнятнее сообщение об ошибке и на выходе ты получишь ад.
Если ты думаешь, что такое встречается очень редко - у меня для тебя плохие новости.
Вынос такого в USE-флаги - тоже не панацея, если нельзя флагами принудительно объяснить пакету A что поддержку B делать не нужно(даже если пакет B установлен). Для пакетов, проверяющих наличие поддержки в рантайме с текущими возможностями USE-флагов это сделать просто НЕЛЬЗЯ.
Вообще мне кажется что я уже по-третьему кругу разжевываю тебе чем чревато такая чехарда с зависимостями. Если тебя не устраивает наличие numpy в системе - у тебя всегда к услугам package.provided. Тут как с user patches - есть поддерживаемая разработчиками конфигурация, есть неподдеживаемая. Это не значит что пользователю нельзя накладывать патчи, просто первым делать попросят пересобрать пакет без них, дабы убедиться что это не они - проблема.
Пока что опциональные зависимости, которые никак не ложатся на парадигму USE-флагов - это неподдерживаемая конфигурация.
Исходная версия Pinkbyte, :
Еще раз - если у тебя есть предложения как работать с опциональными зависимостями так, чтобы не разгребать потом ад с --depclean - добро пожаловать в мэйллист, мы готовы тебя выслушать
Только не забудь случаи вида «пакет А задетектил установленный, но не прописанный по зависимости, опциональный пакет B. Далее пакет C проверяет(тоже опциональную) поддержку B в пакете A и сюрприз, находит её. Потом пользователь выполняет emerge --depclean, пакет B отправляется в /dev/null и пакет C начинает вести себя вообще по-другому, а то и глючить». Продолжи эту линию неучтенных зависимостей, помножь это на то, что чем глубже отсутствующий пакет, тем невнятнее сообщение об ошибке и на выходе ты получишь ад.
Если ты думаешь, что такое встречается очень редко - у меня для тебя плохие новости.
Вынос такого в USE-флаги - тоже не панацея, если нельзя флагами принудительно объяснить пакету A что поддержку B делать не нужно(даже если пакет B установлен). Для пакетов, проверяющих наличие поддержки в рантайме с текущими возможностями USE-флагов это сделать просто НЕЛЬЗЯ.
Вообще мне кажется что я уже по-третьему кругу разжевываю тебе чем чревато такая чехарда с зависимостями. Если тебя не устраивает наличие numpy в системе - у тебя всегда к услугам package.provided. Тут как с user patches - есть поддерживаемая разработчиками конфигурация, есть неподдеживаемая. Это не значит что пользователю нельзя накладывать патчи, просто первым делать попросят пересобрать пакет без них, дабы убедиться что это не они - проблема.
Пока что опциональные зависимости, которые никак не ложатся на парадигму USE-флагов - это неподдерживаемая конфигурация.