Как я препятствую тому, чтобы пакеты программного обеспечения были загружены, пока я не знаю, что это безопасно?

Недавно, обновление, которое вызвало проблему с сессией Gnome, заставило меня терять работу дня. Решение состояло в том, чтобы откатывать некоторые пакеты к предыдущей версии.

Менеджер по обновлению теперь говорит мне, что должны быть обновлены мои старые пакеты:

updating packages I don't want to update

... но я не хочу делать это, пока я не знаю, что безотносительно ошибки или проблемы последняя версия имеет, разрешен.

Я понимаю, что с любым обновлением, что существует риск нестабильности. Однако за эти 8 лет или больше что я был на Ubuntu, использование последних выпусков было достаточно стабильно и с преимуществом последних функций и безопасности. Так, я не ищу общие рекомендации по тому, как обработать обновления.

То, что я говорю, - то, что в этом конкретном экземпляре, ошибка, представленная этими обновлениями, серьезна и время, пропадая впустую. Но, как конечный пользователь, когда я встречаюсь с проблемой как это, я понятия не имею, как обратиться к определенной озабоченности по поводу определенного пакета. Я, например, не знаю, какой из этих пакетов является проблемой, и я не могу занять время из своего графика работ для экспериментирования с каждым пакетом.

Так, мой вопрос:

Как я узнаю, кто точно ответственен за них или кого-либо, пакеты так, чтобы я мог связаться с ними и сообщить им о проблеме?

Как я замораживаю эти пакеты только, но позволяю другим обновлениям происходить?

ubuntu-session
gnome-session-common
gnome-session-bin
gnome-session
3
задан 13 April 2017 в 15:24

2 ответа

Можно предотвратить пакет, чтобы быть udated путем замораживания их.

Вы делаете это как это:

echo "<package name> hold" | sudo dpkg --set-selections

Вы видите список замороженного пакета путем выполнения этого:

dpkg --get-selections|grep hold
2
ответ дан 1 December 2019 в 17:06

Как это было сказано в комментариях, Вы никогда не можете знать, когда "безопасно" обновить пакеты. Представление нового программного обеспечения ALWAYS имеет возможность разрушения Вашей среды.

Поэтому отделы ИТ в компаниях используют тестовые среды и испытывают обновления на подобных машинах прежде, чем развернуть их на их производственных машинах (по крайней мере, любой обладающий чувством собственного достоинства администратор сделал бы так). Можно использовать виртуальные машины также, но это не обязательно позволяет Вам тестировать что-либо связанное с аппаратными средствами или gui (т.е. Ваша проблема гнома), просто базовые сервисы.

Если у Вас нет роскоши тестовой среды, можно быть немного более уверены в обновлениях, если Вы не включаете автоматические обновления (или проверяющий на обновления) и вручную проверяете, существуют ли доступные обновления и просматривают веб-сайты, чтобы видеть, существуют ли любые ошибки, сообщенные с обновлениями. В этом случае всегда изолируйте пару дней/недели позади обновлений (если нет огромная угроза безопасности). Мой личный опыт, хотя, то, что программное обеспечение в эти дни тестируется максимально хорошее, прежде чем оно будет реализовано, и если Вы захотите взять ручной способ проверить все перед установкой, то Вы будете проводить НАМНОГО больше времени, чем Вы были бы на случайном отклонении. И действительно при испытании проблем если Вы хотите защитить себя от выполнения дневной работы для восстановления, необходимо установить некоторую технологию снимков (например, btrfs), который позволяет Вам возвращаться быстро.

Так все, короче говоря никто не отвечает к Вашему запросу, только инструкции по тому, как иметь дело с действительностью. Необходимо решить видеть что работы лучше всего для Вас.

0
ответ дан 1 December 2019 в 17:06

Другие вопросы по тегам:

Похожие вопросы: