On Mon, Jan 29, 2007 at 11:27:40PM +0300, Mikhail Yakshin wrote: >> Я возражаю. Я вообще считаю дурную практику класть конфиги в ~/, а не >> в ~/.etc издевательством. Но, увы, мое мнение явно в меньшинстве, >> потому приходится терпеть это свинство. MY> Можно пример хотя бы 5 пакетов, которые кладут что-то в ~/.etc? Имеет MY> смысл такой практики придерживаться для comfort? Ни одного. Поэтому не имеет. Хотя это и было бы гораздо удобнее. MY> Можно поинтересоваться - с совершенно честными и ясными глазами? Я, MY> наверное, глупый, про git.alt я примерно понимаю еще, как с ним можно MY> работать руками, но какие операции вручную можно делать с incoming.alt? Ну... я сейчас их уже автоматизировал для себя. Но мои скрипты используют, естественно, название 'devel'. MY> Заливка релизов - для этого есть уже с десяток разных скриптов, в MY> comfort есть десяток+первый. Правка ACL - думаю, опять же, лучше MY> довылизывать Sisyphus-acl до состояния, когда бы он всех удовлетворял, MY> чем делать руками "2 rsync туда-обратно + редактирование файла + MY> поискать на вики, где было описание формата этих файлов, потому что MY> формат уже забылся", нет? Да. MY> На ум приходит только всякие операции типа убирания пакетов из incoming MY> (rsync с /var/empty) - но, во-первых, это довольно редкие операции, MY> во-вторых, скоро все этого в любом случае не будет, если будет переезд MY> на тотальный git... Да. Хотя не такие и редкие, но таки вообще-то все что касается incoming/ это временный кошмар. MY> Просмотр списка файлов в incoming и скачивание чего-либо оттуда, пока MY> оно еще не попало в Сизиф - исчезающе редкая операция, скорее всего то MY> же самое все лежит у мейнтейнера в git, даже более свежее... MY> Я все-таки что-то упустил? Я эту операцию часто делаю. Ясное дело для этого используется alias 'ls-devel'. MY> Посмотрел, спасибо, я раньше не знал о существовании этого пакета. Там MY> есть масса полезных вещей (например, gear-rel, svn-update, gi, MY> git-repos-cleanup, send-devel, pkg_release, sisyphus-list-incoming - они MY> все по образу действия по-моему достаточно близки к comfort и хотелось MY> бы их действительно по возможности объединить туда). Я только за. Потому как по моему личному мнению наличие в сизифе каждого пакета с именем "..." это неявная бага. Если пакет seiros-.* используется только у меня, то ему не место в сизифе. А если используется не только мной, то почему бы не объединить все подобные утилиты в один пакет? MY> Относительно некоторых утилит - мне с первого взгляда оказалось не MY> очевидным, что они делают %) MY> Co - это (псевдо)графическая выбиралка и переключалка между бранчами? Да. MY> ptch - для каких работ это предназначено? В git сейчас не проще просто MY> скоммитить все "до" и "после" и вытащить этот патч, если он нужен MY> файлом, просто с помощью разницы между ref'ами? Это для старой эпохи, хотя и сейчас изредка нужно. Есть некий workdir, который не использует никакого SCM. Мы берем в нем и редактируем некоторые файлы, переименовывая оригиналы в *.orig. Потом запускаем этот файл, и получаем вывод по смыслу тот же что если бы мы набрали svn diff/git diff в workdir где они используются. Сейчас я его использую в следующем случае: - rpmbb - В BUILD имеем несобравшийся пакет - переименовываю то что пытаюсь править в .orig и запускаю make (чтобы не пересобирать весь пакет) - повторяю предыдущий шаг до тех пор пока пакет не соберется - ptch > 1.patch - переношу этот патч в каталог с git, и либо привязываю его как новый патч к пакету, либо набираю patch -p0 < 1.patch MY> ptch_filter - один из самых интересных, по идее, скриптов - он как-то MY> хитро фильтрует патчи - но как - я с первого взгляда не понял. Он глючный, поэтому и лежит в отдельном пакете :( Он мне здорово помогал обрабатывать результат сравнения бранчей астериска. MY> Что *именно* делают Add и Mv, кроме наиболее общих "добавляют все, что MY> не добавлено" и "перемещают все массово из одного места в другое" с MY> пустыми commit messages - я так и не понял? Update - зачем там делаются MY> эти хитрые chmod'ы? Add/Mv делают именно это. Наследие тяжелого прошлого когда я хранил _все_ свои данные в svn, естественно далеко не для всех имела смысл история с commit messages. Кстати Mv умеет ключик -b, когда он не пытается коммитить. В случае с git эти скрипты не имеют смысла, потому как есть: git add (делает то же что Add) git mv (который точно так же как Mv прекрасно обрабатывает группы файлов, чего не умеет svn mv). Их имеет смысл паковать только в том случае, если доработать до универсальности (работы как с svn, так и с git репозиториями). Если приходится работать с группой репозиториев в разных SCM, то честно говоря сильно достает использовать разный набор команд для простых операций. Когда-нибудь я озверею и напишу даже скрипт Commit :) Вообще эта группа недоскриптов если и нужна, то их следует упаковать в отдельный пакет. Хотя бы потому что они тянут зависимость и на git, и на svn. А если я чего-нибудь не того выпью, то и на cvs потянут. Вообще многие такие вещи имеет смысл бить на пакеты из-за очень большого объема requires. Кстати глянь ещё на виртуальный пакет appliance-devel-alt. MY> В перспективе - мне хотелось бы еще поговорить с lav@ насчет MY> etersoft-build-utils - т.к. там масса наработок по сборке пакетов и MY> абсолютно не хочется дублировать эту функциональность в comfort, набивая MY> все те же самые грабли, что уже наметили на карте добрые люди и MY> изобретать велосипед (особенно впечатляет там сборка из одного ALT'ового MY> spec в кучу дистрибутивов). В идеале - хотелось бы интегрироваться в ту MY> или другую сторону, т.к. я умышленно сейчас в comfort делал сборку MY> пакетов в очень минимальном виде, а в etersoft-build-utils нет некоего MY> workflow для git. Вместе получилось бы хорошо. Думаю да. В любом случае получится один low level и стайка high level пакетов. Кстати etersoft-build-utils мы с lav@ уже давно допинали до работоспособности с gear. rpmbb в git repo отрабатывает именно так как ожидается. -- С уважением, Денис http://freesource.info ---------------------------------------------------------------------------- > Хм... "А как в Debian" (C)? В Debian все хорошо. -- legion in devel@