Re: [devel] I: gear-tarimport

["Денис Смирнов" <mithraen@altlinux.ru>]

[-- Attachment #1: Type: text/plain, Size: 6420 bytes --]

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> бы их действительно по возможности объединить туда).

Я только за. Потому как по моему личному мнению наличие в сизифе каждого
пакета с именем "<firmname>..." это неявная бага. Если пакет seiros-.*
используется только у меня, то ему не место в сизифе. А если используется
не только мной, то почему бы не объединить все подобные утилиты в один
пакет?

MY> Относительно некоторых утилит - мне с первого взгляда оказалось не
MY> очевидным, что они делают %)
MY> Co - это (псевдо)графическая выбиралка и переключалка между бранчами?

Да.

MY> ptch - для каких работ это предназначено? В git сейчас не проще просто
MY> скоммитить все "до" и "после" и вытащить этот патч, если он нужен
MY> файлом, просто с помощью разницы между ref'ами?

Это для старой эпохи, хотя и сейчас изредка нужно. Есть некий workdir,
который не использует никакого SCM. Мы берем в нем и редактируем
некоторые файлы, переименовывая оригиналы в *.orig. Потом запускаем этот
файл, и получаем вывод по смыслу тот же что если бы мы набрали svn
diff/git diff в workdir где они используются.

Сейчас я его использую в следующем случае:
 - rpmbb <spec>
 - В 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 <specname> в git repo отрабатывает именно
так как ожидается.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
> Хм... "А как в Debian" (C)?
В Debian все хорошо.
		-- legion in devel@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]