Поступила такая "малява". ----- Forwarded message from jiin ----- Date: Thu, 28 Jun 2007 08:59:25 +0600 (YEKST) From: jiin To: mike@osdn Subject: Релиз ALT Linux 4.0.1 Server Новое сообщение от 'jiin' в форуме 'Разговоры, обсуждение новостей' Посмотреть: http://www.opennet.ru/openforum/vsluhforumID3/37729.html#17 Тема: Релиз ALT Linux 4.0.1 Server [...] Кстати интересный бажок такой нашёл. zsh нормально не дополняет по ssh имена хостов. В багзилле запись от 2005 года что исправлено и используется _known_hosts. Так вот по ip оно дополнять не хотело. А в апстриме в _hosts было поправлено по этому поводу в районе 4.3.0 или 4.3.1. И вот только в альтовом zsh нормально не работает zstyle ':completion:*:hosts' use-ip 1 . И что самое интересное изучение srpm мало помогло - патчей там не было. И только изучение http://www.sisyphus.ru/srpm/zsh/patches помогло понять что есть zsh-4.3.0-alt-ssh-known_hosts.patch - вот такой патч. И убрав его все пошло как по маслу. [...] ----------------------------------------------------------- Ответить: http://www.opennet.ru/post/vsluhforumID3/37729/17/ ----- End forwarded message ----- Тут есть два вопроса. Первый вопрос по дополнению ip-адресов, raorn только что помог мне его решить. Второй вопрос по организации src.rpm пакетов. Я уже писал, что мне удобнее всего класть в src.rpm пакеты монолитный %name-%version-%release.tar. Это не то, что люди ожидают увидеть внутри src.rpm пакетов. Поэтому я также писал, что не хотел бы распространять такие src.rpm пакеты. Промежуточный вариант -- сделать кумулятивный патч всех локальных измнениний с помощью .gear-rules. Это тоже не очень удобно, особенно из-за того, что я собираю zsh из cvs snapshot'ов, а не официальных релизов (исторически сложилось так, что очень долго не было официального релиза с поддержкой юникода, а в cvs snapshot'ах оно неплохо работало). То есть каждый раз я перебираюсь на более новый cvs snapshot. Более того, иногда я откручиваю cvs snapshot на несколько коммитов назад, прежде чем делать pull (если вижу наверху потенциально проблемные коммиты). Проблема тут в том, что прежде чем начать собирать snapshot с помощью gear, нужно заранее поставить таг на этот snapshot и внести этот таг в gear-tags. А ведь я заранее не знаю, на каком именно snapshot'е я в конечном счете остановлюсь. В общем, кумулятивный патч из gear-tags более-менее подходит только тогда, когда сборки строго отсчитываются от официальных релизов. Кроме того, кумулятивный патч не слишком-то решает проблемы. Во-первых, он всё же не слишком хорошо удовлетворяет GPL 2a. Во-вторых, как видно из "малявы", люди по-прежнему хотят видеть не только оригинальный тарболл, но и логично нарезнные патчи, которые можно избирательно отключать. Это сделать ещё сложнее. Я подумал и пришел к выводу, что git не очень-то хорошо подходит для поддержки нескольких "логически нарезанных" патчей. Хранить патчи отдельно в таком случае выходит проще, чем думать, как орагинзовать бранчи и как их потом вливать друг в друга. Проблема с git'ом вот какая. Мы сделали измнение относительно версии1. Потом мы делаем pull версии2. merge не проходит из-за конфликта с изменением. Мы вручную правим конфликт. Теперь информаци о том, что представляет из себя изменение относительно версии2, частично потерялась (оно похоронено в ручном разруливании конфликта). То есть уже нельзя логически однозначно восстановить патч для версии2. В идеале нужна такая система, которая позволяет "логически восстанавливать" патч для каждой версии, а не хоронить конфликты под мёржами. ПОСЛЕ КОНФЛИКТНОГО МЁРЖА ПАТЧ УЖЕ НЕЛЬЗЯ ОТКАТИТЬ РЕВЁРТОМ, правильно я понимаю? Я видел какой-то stgit, написанный на питоне. Но не смотрел его как следует.