[devel] Import cvs to git

[devel] Import cvs to git

[Vitaly Ostanin]

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

Здравствуйте.

Скажите, пожалуйста, какой способ импортирования cvs в git сейчас
даёт наилучшие результаты? Например, чтобы импортировать cvs
docs, к которому у меня нет прямого доступа.

Я правильно понимаю, что для перевода пакета на gear с
сохранением истории проекта нужно создавать 2 бранча? Один для
проекта и один для пакета?

Документацию по ссылкам читал, но там не для скудных умом :)
http://wiki.sisyphus.ru/devel/git
http://wiki.sisyphus.ru/devel/gear
http://wiki.sisyphus.ru/devel/gear/ImportSeparateUpstream

В примере с mutt в git импортирована только последняя версия
исходников. Как импортировать всю историю исходников, или их
предыдущие версии?

-- 
Regards, Vyt
mailto:  vyt@vzljot.ru
JID:     vyt@vzljot.ru


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [devel] Import cvs to git

[Sergey Vlasov]

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

On Wed, Jan 24, 2007 at 04:47:17PM +0300, Vitaly Ostanin wrote:
> Скажите, пожалуйста, какой способ импортирования cvs в git сейчас
> даёт наилучшие результаты?

Из-за неустранимых недостатков cvs (прежде всего неатомарности
коммитов) идеальных результатов не даёт ни один метод - за всеми нужно
проверять.  Особенно плохо, если пользователи cvs любят коммитить
файлы с сообщением "empty log message" - в этом случае соседние
коммиты то и дело путаются друг с другом.

Обычно результат parsecvs или cvs2svn -> git-svn ближе к правильному,
чем результат git-cvsimport; с другой стороны, только git-cvsimport
позволяет отслеживать в git последующие изменения, вносимые в cvs.
Впрочем, и за parsecvs, и за cvs2svn во многих случаях приходится
проводить подчистку с помощью cg-admin-uncommit (удалять ничего не
изменяющие коммиты и прочий мусор, порождаемый cvs2svn).

> Например, чтобы импортировать cvs docs, к которому у меня нет
> прямого доступа.

Думаю, что в данном случае проблем с получением такого доступа при
необходимости не возникнет.  Кстати, это имеет смысл сделать даже в
том случае, если в дальнейшем предполагается отслеживать изменения в
cvs через git-cvsimport - хотя git-cvsimport и может обращаться к
удалённому cvs-репозиторию через pserver или ssh, при этом очень
активно потребляется трафик, поскольку git-cvsimport не умеет
запрашивать от сервера патчи (что делает обычный cvs update) - каждая
версия каждого файла будет передана полностью; да и скорость работы в
таком режиме оставляет желать лучшего.  Кстати, этим долгое время
страдал и git-svn - только в последних версиях в git-1.5.0-rcX
реализовали получение с сервера дельт от предыдущих версий файлов.

> Я правильно понимаю, что для перевода пакета на gear с
> сохранением истории проекта нужно создавать 2 бранча? Один для
> проекта и один для пакета?

Да - в одном бранче отслеживаются изменения в оригинальных исходниках
(импортом либо тарболов, либо VCS апстрима), в другом к этим
исходникам добавляются spec-файл, .gear-rules и прочие изменения,
вносимые в пакете.  Конечно, можно завести любое количество
дополнительных бранчей, содержащих отдельные по смыслу изменения (в
этом случае обычно лучше порождать их от оригинальных исходников, а не
от какой-то версии пакета - так проще получить из этого патчи для
отправки в апстрим).

> В примере с mutt в git импортирована только последняя версия
> исходников. Как импортировать всю историю исходников, или их
> предыдущие версии?

Последовательно закоммитить нужные версии в бранч upstream - для
каждой версии удалить старые файлы (git-rm .; в git-1.5.0 нужно ещё
добавить опцию -r), распаковать очередной архив и переименовать
каталог, добавить файлы (git-add .), закоммитить с faketime, создать
тег с указанием версии.

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

[devel] I: gear-tarimport (was: Re: Import cvs to git)

[Aleksey Avdeev]

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

Sergey Vlasov пишет:
> On Wed, Jan 24, 2007 at 04:47:17PM +0300, Vitaly Ostanin wrote:
> 
...
> 
>>В примере с mutt в git импортирована только последняя версия
>>исходников. Как импортировать всю историю исходников, или их
>>предыдущие версии?
> 
> 
> Последовательно закоммитить нужные версии в бранч upstream - для
> каждой версии удалить старые файлы (git-rm .; в git-1.5.0 нужно ещё
> добавить опцию -r), распаковать очередной архив и переименовать
> каталог, добавить файлы (git-add .), закоммитить с faketime, создать
> тег с указанием версии.

  Столкнувшись с достаточно массовой загрузкой траблов -- несколько
автоматизировал процесс: в
<http://git.altlinux.org/people/solo/packages/?p=gear.git> (бранче
solo/tarimport) лежит gear-tarimport.

PS: Результат применения -- в
<http://git.altlinux.ru/people/solo/packages/?p=ulex.git>

-- 

С уважением. Алексей.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 548 bytes --]

Re: [devel] Import cvs to git

[Sergey Vlasov]

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

On Wed, Jan 24, 2007 at 04:47:17PM +0300, Vitaly Ostanin wrote:
> Скажите, пожалуйста, какой способ импортирования cvs в git сейчас
> даёт наилучшие результаты? Например, чтобы импортировать cvs
> docs, к которому у меня нет прямого доступа.

Кстати, появился ещё какой-то проект для преобразования cvs в git или
hg - fromcvs:

http://permalink.gmane.org/gmane.comp.version-control.git/37736

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

Re: [devel] I: gear-tarimport

[Mikhail Yakshin]

Aleksey Avdeev wrote:
> Sergey Vlasov пишет:
>> On Wed, Jan 24, 2007 at 04:47:17PM +0300, Vitaly Ostanin wrote:
>>
> ...
>>> В примере с mutt в git импортирована только последняя версия
>>> исходников. Как импортировать всю историю исходников, или их
>>> предыдущие версии?
>>
>> Последовательно закоммитить нужные версии в бранч upstream - для
>> каждой версии удалить старые файлы (git-rm .; в git-1.5.0 нужно ещё
>> добавить опцию -r), распаковать очередной архив и переименовать
>> каталог, добавить файлы (git-add .), закоммитить с faketime, создать
>> тег с указанием версии.
> 
>   Столкнувшись с достаточно массовой загрузкой траблов -- несколько
> автоматизировал процесс: в
> <http://git.altlinux.org/people/solo/packages/?p=gear.git> (бранче
> solo/tarimport) лежит gear-tarimport.

JFYI - посмотрите на пакет comfort и Sisyphus-archive-import. Он даже в
архив Сизифа сам лазает.

-- 
WBR, Mikhail Yakshin AKA GreyCat
ALT Linux [http://www.altlinux.ru] [xmpp:greycat@altlinux.org]

Re: [devel] I: gear-tarimport

[Alexey I. Froloff]

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

* Mikhail Yakshin <greycat@> [070125 23:05]:
> JFYI - посмотрите на пакет comfort
Это ужоснах, а не пакет, извините, конечно...

Во-первых он использует переменную $GIT_DIR, что конфликтует с
самим git.  Sisyphus-acl можно использовать только один раз в
час, иначе следующий вызов отменит невыполненную команду.
Sisyphus-create зачем-то использует cogito, хотя там хватает git.
Зеркало Сизифа захардкодено в /Sisyphus.  Захардкодены имена
git.alt и incoming.alt и эти имена должны быть первым словом
после "Host".  Приватный ключ должен лежать в ~/.ssh/id_dsa.
$BUILD_DIR должны совпадать на локальной машине и на
$BUILD_SERVER...

Это я минут 15 поразглядывал исходники...

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

Я бы на самом деле хотел вынести мелкие занудные действия, типа
создание .gear-rules, обновление сорцов в бранче upstream и т.п.
в отдельный пакет...  Вещи - общие для всех разработчиков и не
привязанные к Сизифу, git.alt и прочим incoming'ам...

P.S. Рекомендую посмотреть на gear-hsh-build.

-- 
Regards,
Sir Raorn.

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

Re: [devel] I: gear-tarimport

[Mikhail Yakshin]

Alexey I. Froloff wrote:
> * Mikhail Yakshin <greycat@> [070125 23:05]:
>> JFYI - посмотрите на пакет comfort
> Это ужоснах, а не пакет, извините, конечно...

Спасибо за конструктивную критику :)

> Во-первых он использует переменную $GIT_DIR, что конфликтует с
> самим git.

Не конфликтует. Он ее использует узко в своих скриптах - а там она
ничему не мешает. Я с примерами использования $GIT_DIR на практике
сталкивался только в каких-то довольно advanced вызовах низкоуровневого
git plumbing - там, когда надо с двумя .git одновременно работать,
например, или что-то такое. В реальной жизни пока сам ни разу ее по
назначению внутри git не использовал.

Впрочем, думаю, действительно, на будущее - стоит ее переименовать в,
например, GIT_ROOT_DIR.

> Sisyphus-acl можно использовать только один раз в
> час, иначе следующий вызов отменит невыполненную команду.

Неправда.

> Sisyphus-create зачем-то использует cogito, хотя там хватает git.

cogito должен быть в зависимостях у comfort - так, что, наверное, не
принципиально что использовать. Если кому-то принципиально понадобится
comfort без cogito - patches are welcome. Впрочем, видимо, те, кто не
пользуются cogito, не будут пользоваться и comfort.

> Зеркало Сизифа захардкодено в /Sisyphus.

Будет исправлено, чтобы искать его через конфиг апта.

> Захардкодены имена
> git.alt и incoming.alt и эти имена должны быть первым словом
> после "Host".

Зачем может быть нужно использовать другие имена? Тогда ровно тот же
вопрос правомерен в отношении git.altlinux.org, cvs.altlinux.org,
ftp.altlinux.org (хотя тут в будущем как раз может понадобится выбор
альтерантив) и т.д.

> Приватный ключ должен лежать в ~/.ssh/id_dsa.

Неправда.

> $BUILD_DIR должны совпадать на локальной машине и на
> $BUILD_SERVER...

Будет исправлено. Хотя - с другой стороны - настолько гибким все делать
- можно довести до абсурдных ситуаций - к каждой машине, например,
задавать username,  почему бы не иметь

> Всё что прибито гвоздями - ограничивает свободу использования
> пакета.

И это хорошо - в этом и мысль.

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

Логично, он на это, в общем, пока не претендует.

> Я бы на самом деле хотел вынести мелкие занудные действия, типа
> создание .gear-rules, обновление сорцов в бранче upstream и т.п.
> в отдельный пакет...  Вещи - общие для всех разработчиков и не
> привязанные к Сизифу, git.alt и прочим incoming'ам...

> P.S. Рекомендую посмотреть на gear-hsh-build.

Смотрел, это программа именно уровня gear-* - инструмент такого
middle-tier. Ее можно использовать действительно для поддержания пачки
самосбора, Дедалуса, можно найти и массу других применений.

-- 
WBR, Mikhail Yakshin AKA GreyCat
ALT Linux [http://www.altlinux.ru] [xmpp:greycat@altlinux.org]

Re: [devel] I: gear-tarimport

[Kirill Maslinsky]

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

On Fri, Jan 26, 2007 at 01:59:01AM +0300, Mikhail Yakshin wrote:
> Alexey I. Froloff wrote:

[...]

> > Sisyphus-create зачем-то использует cogito, хотя там хватает git.
> 
> cogito должен быть в зависимостях у comfort - так, что, наверное, не
> принципиально что использовать. Если кому-то принципиально понадобится
> comfort без cogito - patches are welcome. Впрочем, видимо, те, кто не
> пользуются cogito, не будут пользоваться и comfort.

Совершенно необоснованное утрверждение и даже с опровергающим примером
в моем лице: comfort рассчитываю использовать, а cogito нет.

Можно ли перечислить задачи, которые реально необходимо делать в comfort 
с помощью cogito? 
Или дело просто в том, что вы хотите подобрать и предложить мантейнеру
некий вариант готовой рабочей среды?
В последнем случае правильнее создать виртуальный пакет, какой-нибудь
comfort-environment, и пусть он на все зависит. А самому comfort'у 
оставить только необходимые зависимости -- это позволит сделать 
пакет более инструментальным в глазах пользователей, с меньшим 
оттенком "вкусовщины".

> > $BUILD_DIR должны совпадать на локальной машине и на
> > $BUILD_SERVER...
> 
> Будет исправлено. Хотя - с другой стороны - настолько гибким все делать
> - можно довести до абсурдных ситуаций - к каждой машине, например,
> задавать username,  почему бы не иметь

А что в этом абсурдного? У меня на локальной машине и на сборочном сервере
разные username. Или  речь о другом?

> > Всё что прибито гвоздями - ограничивает свободу использования
> > пакета.
> 
> И это хорошо - в этом и мысль.

Наверное, мысль все-таки не в том, чтобы ограничивать свободу, 
а в том, чтобы зафиксировать и атомизировать с помощью утилит
распространенные и удачные паттерны, связанные с разработкой Сизифа?

-- 
Kirill Maslinsky
ALT Linux Documentation Team
http://heap.altlinux.ru

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

Re: [devel] I: gear-tarimport

[Mikhail Yakshin]

Kirill Maslinsky пишет:
> On Fri, Jan 26, 2007 at 01:59:01AM +0300, Mikhail Yakshin wrote:
>> Alexey I. Froloff wrote:
> 
> [...]
> 
>>> Sisyphus-create зачем-то использует cogito, хотя там хватает git.
>> cogito должен быть в зависимостях у comfort - так, что, наверное, не
>> принципиально что использовать. Если кому-то принципиально понадобится
>> comfort без cogito - patches are welcome. Впрочем, видимо, те, кто не
>> пользуются cogito, не будут пользоваться и comfort.
> 
> Совершенно необоснованное утрверждение и даже с опровергающим примером
> в моем лице: comfort рассчитываю использовать, а cogito нет.

Хорошо, если есть желание - тогда другой разговор. А можно в свою 
очередь мне поинтересоваться, зачем использовать именно голый git?

> Можно ли перечислить задачи, которые реально необходимо делать в comfort 
> с помощью cogito?

Никакие задачи не требуют обязательного использования cogito - это в 
свою очередь просто несложная оболочка над git-*. Разумеется, все можно 
переписать с использованием только этих утилит.

> Или дело просто в том, что вы хотите подобрать и предложить мантейнеру
> некий вариант готовой рабочей среды?

Именно так - чтобы можно было 1-2 командами подготовить рабочее место к 
работе. apt-get install comfort && Sisyphus-setup.

> В последнем случае правильнее создать виртуальный пакет, какой-нибудь
> comfort-environment, и пусть он на все зависит. А самому comfort'у 
> оставить только необходимые зависимости -- это позволит сделать 
> пакет более инструментальным в глазах пользователей, с меньшим 
> оттенком "вкусовщины".

В таком случае, наверное, так и стоит поступить.

>>> $BUILD_DIR должны совпадать на локальной машине и на
>>> $BUILD_SERVER...
>> Будет исправлено. Хотя - с другой стороны - настолько гибким все делать
>> - можно довести до абсурдных ситуаций - к каждой машине, например,
>> задавать username,  почему бы не иметь
> 
> А что в этом абсурдного? У меня на локальной машине и на сборочном сервере
> разные username. Или  речь о другом?

Речь об этом. В целом - это нетрадиционно и довольно неественно - если 
так сделано - на то есть причины и очень может быть, что вся 
инфраструктура в целом будет не очень хорошо ложится на то, что 
предлагается в comfort.

Впрочем, если кому-то нужно именно это - то, конечно, всегда можно 
сделать еще одну опцию, не проблема.

>>> Всё что прибито гвоздями - ограничивает свободу использования
>>> пакета.
>> И это хорошо - в этом и мысль.
> 
> Наверное, мысль все-таки не в том, чтобы ограничивать свободу, 
> а в том, чтобы зафиксировать и атомизировать с помощью утилит
> распространенные и удачные паттерны, связанные с разработкой Сизифа?

Ну, это примерно то же самое, сказанное более политкорректными словами ;)

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

Если есть готовое решение, скажем - RPM, где по умолчанию у всех все 
поставлено в ~/RPM, там внутри - тоже вполне hardcoded структура 
директорий - то мало кто будет даже задумываться о том, чтобы менять 
это. Другой вопрос, чтобы иметь возможность менять в случае, когда это 
действительно нужно (человек делает какое-то свое, другое решение, на 
базе этого, применяя всю схему несколько нетрадиционно) - но тут вопрос, 
где провести границу между мириадами возможных настроек и "use the source".

Я пока провожу по принципу "что было нужно мне и что просили до сих 
пор". Если хотя бы одному человеку что-то правда нужно - и это можно 
реализовать, не помешав остальной части пакета - то это делается.

-- 
WBR, GreyCat

Re: [devel] I: gear-tarimport

[Anton Farygin]

Mikhail Yakshin wrote:
> Kirill Maslinsky пишет:
>> On Fri, Jan 26, 2007 at 01:59:01AM +0300, Mikhail Yakshin wrote:
>>> Alexey I. Froloff wrote:
>> [...]
>>
>>>> Sisyphus-create зачем-то использует cogito, хотя там хватает git.
>>> cogito должен быть в зависимостях у comfort - так, что, наверное, не
>>> принципиально что использовать. Если кому-то принципиально понадобится
>>> comfort без cogito - patches are welcome. Впрочем, видимо, те, кто не
>>> пользуются cogito, не будут пользоваться и comfort.
>> Совершенно необоснованное утрверждение и даже с опровергающим примером
>> в моем лице: comfort рассчитываю использовать, а cogito нет.
> 
> Хорошо, если есть желание - тогда другой разговор. А можно в свою 
> очередь мне поинтересоваться, зачем использовать именно голый git?

Миша, у cogito есть исправимые недостатки, которые исправлять всем
наверное влом.

В частности - разница между:
gir-rm -f <имя>-1.tar
git-add <имя>-2.tar

дают совершенно разный результат по сравнению с cogito

> 
>> Можно ли перечислить задачи, которые реально необходимо делать в comfort 
>> с помощью cogito?
> 
> Никакие задачи не требуют обязательного использования cogito - это в 
> свою очередь просто несложная оболочка над git-*. Разумеется, все можно 
> переписать с использованием только этих утилит.

Я бы не сказал, что это простая оболочка...

Rgds,
Rider

Re: [devel] I: gear-tarimport

[Aleksey Avdeev]

Mikhail Yakshin пишет:
> Aleksey Avdeev wrote:
>> Sergey Vlasov пишет:
>>> On Wed, Jan 24, 2007 at 04:47:17PM +0300, Vitaly Ostanin wrote:
>>>
>> ...
>>>> В примере с mutt в git импортирована только последняя версия
>>>> исходников. Как импортировать всю историю исходников, или их
>>>> предыдущие версии?
>>> Последовательно закоммитить нужные версии в бранч upstream - для
>>> каждой версии удалить старые файлы (git-rm .; в git-1.5.0 нужно ещё
>>> добавить опцию -r), распаковать очередной архив и переименовать
>>> каталог, добавить файлы (git-add .), закоммитить с faketime, создать
>>> тег с указанием версии.
>>   Столкнувшись с достаточно массовой загрузкой траблов -- несколько
>> автоматизировал процесс: в
>> <http://git.altlinux.org/people/solo/packages/?p=gear.git> (бранче
>> solo/tarimport) лежит gear-tarimport.
> 
> JFYI - посмотрите на пакет comfort и Sisyphus-archive-import. Он даже в
> архив Сизифа сам лазает.

   Пока до него недобрался.

PS: Судя по описаним -- слишком монстоподобен... ;-)

-- 

С уважением. Алексей.

Re: [devel] I: gear-tarimport

[Mikhail Yakshin]

Aleksey Avdeev wrote:
>>>   Столкнувшись с достаточно массовой загрузкой траблов -- несколько
>>> автоматизировал процесс: в
>>> <http://git.altlinux.org/people/solo/packages/?p=gear.git> (бранче
>>> solo/tarimport) лежит gear-tarimport.
>> JFYI - посмотрите на пакет comfort и Sisyphus-archive-import. Он даже в
>> архив Сизифа сам лазает.
> 
>    Пока до него недобрался.
> 
> PS: Судя по описаним -- слишком монстоподобен... ;-)

;) А я так старался, чтобы оно было простым и прозрачным.

Sisyphus-archive-import состоит из 2 строчек: вызова archive-download и 
archive-import. Каждый из них - еще 12-13 строчек. Итого около 25 
строчек. Я не очень представляю, как это можно сделать проще и прозрачней %)

-- 
WBR, Mikhail Yakshin.

Re: [devel] I: gear-tarimport

[Aleksey Avdeev]

Mikhail Yakshin пишет:
> Aleksey Avdeev wrote:
>>>>   Столкнувшись с достаточно массовой загрузкой траблов -- несколько
>>>> автоматизировал процесс: в
>>>> <http://git.altlinux.org/people/solo/packages/?p=gear.git> (бранче
>>>> solo/tarimport) лежит gear-tarimport.
>>> JFYI - посмотрите на пакет comfort и Sisyphus-archive-import. Он даже в
>>> архив Сизифа сам лазает.
>>    Пока до него недобрался.
>>
>> PS: Судя по описаним -- слишком монстоподобен... ;-)
> 
> ;) А я так старался, чтобы оно было простым и прозрачным.
> 
> Sisyphus-archive-import состоит из 2 строчек: вызова archive-download и 
> archive-import. Каждый из них - еще 12-13 строчек. Итого около 25 
> строчек. Я не очень представляю, как это можно сделать проще и прозрачней %)

   Я пока не на столько крут: я ещё только подбираю нужные мне строчки. 
  А насколько мне подходят мне вашы -- пока незнаю. Но посмотрю. ;-)

-- 

С уважением. Алексей.

Re: [devel] I: gear-tarimport

[Kirill Maslinsky]

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

On Fri, Jan 26, 2007 at 01:57:23PM +0300, Mikhail Yakshin wrote:
> Kirill Maslinsky пишет:
> > [...]
> > 
> >>> Sisyphus-create зачем-то использует cogito, хотя там хватает git.
> >> cogito должен быть в зависимостях у comfort - так, что, наверное, не
> >> принципиально что использовать. Если кому-то принципиально понадобится
> >> comfort без cogito - patches are welcome. Впрочем, видимо, те, кто не
> >> пользуются cogito, не будут пользоваться и comfort.
> > 
> > Совершенно необоснованное утрверждение и даже с опровергающим примером
> > в моем лице: comfort рассчитываю использовать, а cogito нет.
> 
> Хорошо, если есть желание - тогда другой разговор. А можно в свою 
> очередь мне поинтересоваться, зачем использовать именно голый git?

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

Мне кажется, такой пакет, как comfort, может стать по-настоящему полезным,
только если он будет аккумулировать опыт больее чем одного человека.

> > Можно ли перечислить задачи, которые реально необходимо делать в comfort 
> > с помощью cogito?
> 
> Никакие задачи не требуют обязательного использования cogito - это в 
> свою очередь просто несложная оболочка над git-*. Разумеется, все можно 
> переписать с использованием только этих утилит.
> 

> >>> Всё что прибито гвоздями - ограничивает свободу использования
> >>> пакета.
> >> И это хорошо - в этом и мысль.
> > 
> > Наверное, мысль все-таки не в том, чтобы ограничивать свободу, 
> > а в том, чтобы зафиксировать и атомизировать с помощью утилит
> > распространенные и удачные паттерны, связанные с разработкой Сизифа?
> 
> Ну, это примерно то же самое, сказанное более политкорректными словами ;)
> 
> С моей точки зрения - как раз когда дают инструменты и много свободы к 
> ним в придачу - это плохо. Каждое лишнее решение, не придуманное за 
> мейнтенера заранее, каждому человеку приходится принимать самостоятельно 
> и что-то изобретать, причем все начинают это делать по-разному, а потом 
> привыкают.

Вот, сказано еще точнее! Этот абзац надо бы в README comfort вставить, 
в качестве обоснования и агитации.

-- 
Kirill Maslinsky
ALT Linux Documentation Team
http://heap.altlinux.ru

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

Re: [devel] I: gear-tarimport

[Alexey I. Froloff]

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

* Mikhail Yakshin <greycat@> [070126 14:07]:
> С моей точки зрения - как раз когда дают инструменты и много свободы к 
> ним в придачу - это плохо. Каждое лишнее решение, не придуманное за 
> мейнтенера заранее, каждому человеку приходится принимать самостоятельно 
> и что-то изобретать,
Венда какая-то получается.  "Билли, ты всегда думаешь за нас".
:-/

> причем все начинают это делать по-разному, а потом привыкают.
Нам важен процесс или результат?

> Если есть готовое решение, скажем - RPM, где по умолчанию у всех все 
> поставлено в ~/RPM, там внутри - тоже вполне hardcoded структура 
> директорий - то мало кто будет даже задумываться о том, чтобы менять 
> это.
У меня возникает такое желание.  И два года всё работает только
правкой ~/.rpmrc.  Как например.

> но тут вопрос, где провести границу между мириадами возможных
> настроек и "use the source".
Всё что не влияет на конечный результат должно быть настраиваемо.
Либо определяться из настроек другого софта (например rpm,
sisyphus).

Разумные умолчания - это хорошо, но ограничивать свободу
пользователя этим умолчаниями просто глупо...  Я сейчас просто не
могу пользоваться Sisyphus-comfort потому как придётся тупо
менять настройки того же ssh.

-- 
Regards,
Sir Raorn.

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

Re: [devel] I: gear-tarimport

[Alexey I. Froloff]

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

* Mikhail Yakshin <greycat@> [070126 02:05]:
> > Sisyphus-acl можно использовать только один раз в
> > час, иначе следующий вызов отменит невыполненную команду.
> Неправда.
Да, это я протупил.

> > Sisyphus-create зачем-то использует cogito, хотя там хватает git.
> cogito должен быть в зависимостях у comfort - так, что, наверное, не
> принципиально что использовать. Если кому-то принципиально понадобится
> comfort без cogito - patches are welcome. Впрочем, видимо, те, кто не
> пользуются cogito, не будут пользоваться и comfort.
Вопрос стоит так - зачем пользоваться надстройкой над git там,
где хватает функциональности самого git?

> > Захардкодены имена git.alt и incoming.alt и эти имена должны
> > быть первым словом после "Host".
> Зачем может быть нужно использовать другие имена?
Хотя бы затем, что пару лет назад incoming.alt назывался
devel.alt.

> > Приватный ключ должен лежать в ~/.ssh/id_dsa.
> Неправда.
Значит уже исправлено.  В Sisyphus-setup было именно так.

> > Всё что прибито гвоздями - ограничивает свободу использования
> > пакета.
> И это хорошо - в этом и мысль.
Неправильная мысль.

> > P.S. Рекомендую посмотреть на gear-hsh-build.
> Смотрел, это программа именно уровня gear-* - инструмент такого
> middle-tier. Ее можно использовать действительно для поддержания пачки
> самосбора, Дедалуса, можно найти и массу других применений.
Я к тому, что оно может собирать пакеты и вытаскивать результат в
указанное место.  Может пригодиться.

-- 
Regards,
Sir Raorn.

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

Re: [devel] I: gear-tarimport

[Mikhail Yakshin]

Kirill Maslinsky wrote:
> On Fri, Jan 26, 2007 at 01:57:23PM +0300, Mikhail Yakshin wrote:
>> Kirill Maslinsky пишет:
>>> [...]
>>>
>>>>> Sisyphus-create зачем-то использует cogito, хотя там хватает git.
>>>> cogito должен быть в зависимостях у comfort - так, что, наверное, не
>>>> принципиально что использовать. Если кому-то принципиально понадобится
>>>> comfort без cogito - patches are welcome. Впрочем, видимо, те, кто не
>>>> пользуются cogito, не будут пользоваться и comfort.
>>> Совершенно необоснованное утрверждение и даже с опровергающим примером
>>> в моем лице: comfort рассчитываю использовать, а cogito нет.
>> Хорошо, если есть желание - тогда другой разговор. А можно в свою 
>> очередь мне поинтересоваться, зачем использовать именно голый git?
> 
> Ну поскольку cogito по архитектуре не требуется, а просто является
> некой оберткой над git -- оно тем самым привносит дополнительный
> уровень в логику работы, в общем случае от этого сложнее разобраться
> в исходном тексте, что-то запатчить... К тому же наверняка просто
> git знает в сумме больше людей, чем любую из оберток над ним. 

Нет, это не так. К сожалению, в ALT - это так, так многим пришлось 
изучать досконально все git-* для того, чтобы это использовать. git, в 
общем-то, как у него и написано на сайте, не является SCM, а является 
неким тулкитом для построения оной. И по моим личным наблюдениям, и судя 
по тем же туториалам и quickstart'ам в документации git, cogito гораздо 
больше напоминает SCM - не в последнюю очередь "похожестью" на точку 
зрения традиционных SCM.

Вообще еще один весьма спорный, но тем не менее тезис - мейнтейнер не 
обязан перед использованием любого инструмента (того же git) досконально 
изучать его исходники, вникать в сложную внутреннюю терминологию и т.п. 
Достаточно того, что у него сверху есть 5-6 ручек, за которые он может 
дергать c кратко и четко описаным поведением, и абсолютно 
детерминированным результатом.

> Мне кажется, такой пакет, как comfort, может стать по-настоящему полезным,
> только если он будет аккумулировать опыт больее чем одного человека.

Надеюсь :)

>>>>> Всё что прибито гвоздями - ограничивает свободу использования
>>>>> пакета.
>>>> И это хорошо - в этом и мысль.
>>> Наверное, мысль все-таки не в том, чтобы ограничивать свободу, 
>>> а в том, чтобы зафиксировать и атомизировать с помощью утилит
>>> распространенные и удачные паттерны, связанные с разработкой Сизифа?
>> Ну, это примерно то же самое, сказанное более политкорректными словами ;)
>>
>> С моей точки зрения - как раз когда дают инструменты и много свободы к 
>> ним в придачу - это плохо. Каждое лишнее решение, не придуманное за 
>> мейнтенера заранее, каждому человеку приходится принимать самостоятельно 
>> и что-то изобретать, причем все начинают это делать по-разному, а потом 
>> привыкают.
> 
> Вот, сказано еще точнее! Этот абзац надо бы в README comfort вставить, 
> в качестве обоснования и агитации.

Хорошо :)

-- 
WBR, Mikhail Yakshin

Re: [devel] I: gear-tarimport

[Mikhail Yakshin]

Alexey I. Froloff wrote:
>>> Sisyphus-create зачем-то использует cogito, хотя там хватает git.
>> cogito должен быть в зависимостях у comfort - так, что, наверное, не
>> принципиально что использовать. Если кому-то принципиально понадобится
>> comfort без cogito - patches are welcome. Впрочем, видимо, те, кто не
>> пользуются cogito, не будут пользоваться и comfort.
> Вопрос стоит так - зачем пользоваться надстройкой над git там,
> где хватает функциональности самого git?

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

>>> Захардкодены имена git.alt и incoming.alt и эти имена должны
>>> быть первым словом после "Host".
>> Зачем может быть нужно использовать другие имена?
> Хотя бы затем, что пару лет назад incoming.alt назывался
> devel.alt.

Если он у всех будет называться incoming.alt - разве это будет плохо?

>>> Приватный ключ должен лежать в ~/.ssh/id_dsa.
>> Неправда.
> Значит уже исправлено.  В Sisyphus-setup было именно так.

Имя файла с приватным ключом задается переменной $ALT_SSH_KEY и легко 
переопределяется в ~/.Sisyphusrc. У меня, скажем, он лежит в 
~/.ssh/id_dsa_alt.

-- 
WBR, Mikhail Yakshin

Re: [devel] I: gear-tarimport

[Alexey I. Froloff]

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

* Mikhail Yakshin <greycat@> [070127 17:42]:
> > Вопрос стоит так - зачем пользоваться надстройкой над git там,
> > где хватает функциональности самого git?
> Можно легко поставить и противоположный вопрос - зачем пользоваться 
> инструментом низкого уровня, вызывая много сложных команд, когда я могу 
> напрямую вызвать инструмент высокого уровня, выполнив одну команду, 
> которая для этого конкретного случая идеально подходит?
Ты - да.  Но зачем это навязывать в инструменте?

> > Хотя бы затем, что пару лет назад incoming.alt назывался
> > devel.alt.
> Если он у всех будет называться incoming.alt - разве это будет плохо?
Чем плохо, если это будет настраиваться?

-- 
Regards,
Sir Raorn.

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

Re: [devel] git: plumbing or porcelain

[Dmitry V. Levin]

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

On Sat, Jan 27, 2007 at 04:08:48PM +0300, Kirill Maslinsky wrote:
> On Fri, Jan 26, 2007 at 01:57:23PM +0300, Mikhail Yakshin wrote:
[...]
> > Хорошо, если есть желание - тогда другой разговор. А можно в свою 
> > очередь мне поинтересоваться, зачем использовать именно голый git?
> 
> Ну поскольку cogito по архитектуре не требуется, а просто является
> некой оберткой над git -- оно тем самым привносит дополнительный
> уровень в логику работы, в общем случае от этого сложнее разобраться
> в исходном тексте, что-то запатчить... К тому же наверняка просто
> git знает в сумме больше людей, чем любую из оберток над ним. 

Всё то время, в течение которого я использую git, наблюдаю увеличение с
каждой версией доли porcelain (высокоуровневых обёрток над
низкоуровневыми инструкциями).  Так что мне кажется, что со временем
различие между git и cogito в этой области будет всё меньше и меньше.


-- 
ldv

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

Re: [devel] I: gear-tarimport

[Mikhail Gusarov]

AIF> > > Всё что прибито гвоздями - ограничивает свободу использования
AIF> > > пакета.
AIF> > И это хорошо - в этом и мысль.
AIF> Неправильная мысль.

+1. Неправильная. Поясню.

Ограничение свободы сборщика пакета должно происходить только в одном
случае: когда неограниченная свобода мешает совместимости. Если не
следовать этому правилу, а насильно загонять в "светлое будущее", то
все добровольные сборщики очень быстро разбегутся (что и наблюдается
сейчас).

Разбегутся по двум соображениям:

1) если сборщики не хотят идти в "светлое будущее" своими ногами, то
это означает, что это "светлое будущее" либо недостаточно
документировано, чтобы понять его "светлость", либо не настолько
"светло".

2) Процесс применения административной силы при загоне показывает, что
в коммунити все равны, но некоторые ровнее. Это заставляет понять, что
добровольные сборщики являются de facto бесплатной рабочей силой для
ООО, а кому это нравится?

ps: более развёрнутое исследование будет позже.

-- 
JID: dottedmag@jabber.dottedmag.net

Re: [devel] comfort

[Dmitry V. Levin]

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

On Fri, Jan 26, 2007 at 01:57:23PM +0300, Mikhail Yakshin wrote:
[...]
> С моей точки зрения - как раз когда дают инструменты и много свободы к 
> ним в придачу - это плохо.

Почему?

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

Я не вижу, почему из наличия широкого спектра инструментария автоматически
следует недостаток готовых решений.


-- 
ldv

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

Re: [devel] I: gear-tarimport

[Mikhail Yakshin]

Alexey I. Froloff wrote:
> * Mikhail Yakshin <greycat@> [070127 17:42]:
>>> Вопрос стоит так - зачем пользоваться надстройкой над git там,
>>> где хватает функциональности самого git?
>> Можно легко поставить и противоположный вопрос - зачем пользоваться 
>> инструментом низкого уровня, вызывая много сложных команд, когда я могу 
>> напрямую вызвать инструмент высокого уровня, выполнив одну команду, 
>> которая для этого конкретного случая идеально подходит?
> Ты - да.  Но зачем это навязывать в инструменте?

Я понял, что у нас разные мнения по этому вопросу. Я исправил:

http://git.altlinux.org/people/greycat/packages/?p=comfort.git;a=commit;h=dc7b08b238eefd9d0ca5413e76246574cb248b54

>>> Хотя бы затем, что пару лет назад incoming.alt назывался
>>> devel.alt.
>> Если он у всех будет называться incoming.alt - разве это будет плохо?
> Чем плохо, если это будет настраиваться?

Хотя бы одному человеку это нужно?

-- 
WBR, GreyCat

Re: [devel] I: gear-tarimport

[Michael Shigorin]

On Sat, Jan 27, 2007 at 06:39:39PM +0300, Mikhail Yakshin wrote:
> >>> Хотя бы затем, что пару лет назад incoming.alt назывался
> >>> devel.alt.
> >> Если он у всех будет называться incoming.alt - разве это
> >> будет плохо?
> > Чем плохо, если это будет настраиваться?
> Хотя бы одному человеку это нужно?

Хорошо, когда вещи, которые могут зависеть от вкусов и привычек
(особенно в случае, когда рекомендуемое значение менялось со
временем), имеют разумные в данный момент значения по умолчанию,
которые при этом возможно изменить без правки кода или привычки.

У меня этот алиас -- просто "incoming".

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] I: gear-tarimport

[Sviatoslav Sviridov]

Mikhail Yakshin пишет:
> ...
>   
>>>> Хотя бы затем, что пару лет назад incoming.alt назывался
>>>> devel.alt.
>>>>         
>>> Если он у всех будет называться incoming.alt - разве это будет плохо?
>>>       
>> Чем плохо, если это будет настраиваться?
>>     
>
> Хотя бы одному человеку это нужно?
>   
не знаю, нужно мне это или нет, но incoming.alt у меня в .ssh/config нет 
:) По историческим причинам там у меня другое имя прописано, и не вижу 
причин начильственно приводить всех к одной гребенке :).

-- 
Best regards,
Sviatoslav Sviridov

Re: [devel] I: gear-tarimport

[Alexey I. Froloff]

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

* Mikhail Yakshin <greycat@> [070126 02:05]:
> >> JFYI - посмотрите на пакет comfort
> > Это ужоснах, а не пакет, извините, конечно...
> Спасибо за конструктивную критику :)
Ещё один момент - не лучше архитектуру для сборки брать из
~/.hasher/config?  Просто спросил.

-- 
Regards,
Sir Raorn.

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

[devel] [flame] было про сomfort, стало про spt.

[Denis Medvedev]

> On Fri, Jan 26, 2007 at 01:57:23PM +0300, Mikhail Yakshin wrote:
> [...]
> > С моей точки зрения - как раз когда дают инструменты и много свободы к 
> > ним в придачу - это плохо.
> 
> Почему?
> 
> > Каждое лишнее решение, не придуманное за 
> > мейнтенера заранее, каждому человеку приходится принимать самостоятельно 
> > и что-то изобретать, причем все начинают это делать по-разному, а потом 
> > привыкают.
> 
> Я не вижу, почему из наличия широкого спектра инструментария автоматически
> следует недостаток готовых решений.

Я согласен с Михаилом Якшиным и готов ему отпарировать на основе его же spt3.
Вот был у нас НОРМАЛЬНЫЙ spt. Выполнял свою задачу. Им пользовались ВСЕ и работали с ним. Нет ну надо было 
а) Выкатить СОВЕРШЕННО другой продукт,
б) Назвать его как следующую версию spt, введя в заблуждение тех, кто думал что это действительно следующая версия.
в) Поддерживать его в постоянно нерабочем состоянии.
Что теперь делать? На что ориентироваться чтобы собирать себе appliance или специальный инсталлятор, или livecd в стиле mainstream?

Re: [devel] I: gear-tarimport

[Денис Смирнов]

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

On Sat, Jan 27, 2007 at 05:30:27PM +0300, Mikhail Yakshin wrote:

MY> Если он у всех будет называться incoming.alt - разве это будет плохо?

Если инструмент мне _диктует_ такие вещи -- он отправляется в /dev/null.
Даже без любых попыток тратить время на этот инструмент.

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

http://freesource.info
----------------------------------------------------------------------------
* combr идийот - невнимательно прочитал man formail и два дня страдал фигней ;)

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

Re: [devel] I: gear-tarimport

[Mikhail Yakshin]

Alexey I. Froloff wrote:
> * Mikhail Yakshin <greycat@> [070126 02:05]:
>>>> JFYI - посмотрите на пакет comfort
>>> Это ужоснах, а не пакет, извините, конечно...
>> Спасибо за конструктивную критику :)
> Ещё один момент - не лучше архитектуру для сборки брать из
> ~/.hasher/config?  Просто спросил.

Да, спасибо, сделаю.

-- 
WBR, GreyCat

Re: [devel] I: gear-tarimport

[Mikhail Yakshin]

Денис Смирнов wrote:
> On Sat, Jan 27, 2007 at 05:30:27PM +0300, Mikhail Yakshin wrote:
> 
> MY> Если он у всех будет называться incoming.alt - разве это будет плохо?
> 
> Если инструмент мне _диктует_ такие вещи -- он отправляется в /dev/null.
> Даже без любых попыток тратить время на этот инструмент.

Вот есть пакет, который filesystem. Он _диктует_, что в системе должна 
быть директории, например /srv и /media. Он тоже в /dev/null без попыток 
тратить время?

Есть инструмент, который git.altlinux.org - он, как ни тресни, имеет 
хостнейм git.altlinux.org - и он тоже _диктует_, что . Его тоже?

Есть инструмент, который, например, ssh - он кладет конфиги пользователя 
в ~/.ssh и почему-то мало кто возражает.

В пакете есть user-defined опции типа $GIT_HOME_DIR или $BUILD_DIR, их, 
по-моему, имеет смысл переопределять - в эти директории люди ходят 
руками, набирают "cd что-нибудь" - тут есть вопрос в 
удобстве-неудобстве, кому какое имя нравится и приятно видеть. В конце 
концов, директории полезно иметь переопределяемыми, чтобы перенести их 
на другие файловые системы, какой-нибудь /srv/development, который лежит 
где-нибудь аж нелокально.

Зачем иметь разные названия incoming.alt и git.alt, отличающиеся от 
рекомендованных - я пока не могу придумать. Запуск "Sisyphus-setup" 
позволяет убедиться в том, что в конфиге ssh эти алиасы есть и позволяет 
за ними не следить. В идеале - вручную набирать где-либо incoming.alt и 
git.alt не должно быть нужно - мейнтейнер вообще может о них ничего не 
знать.

Опять же - если как в случае с cogito - если кто-то скажет, что ему 
действительно нужно иначе - это все делается в 3 строчки, абсолютно 
проблема.

-- 
WBR, Mikhail Yakshin AKA GreyCat

Re: [devel] I: gear-tarimport

[Alexey Tourbin]

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

On Sat, Jan 27, 2007 at 07:57:28PM +0200, Sviatoslav Sviridov wrote:
> Mikhail Yakshin пишет:
> > Хотя бы одному человеку это нужно?
> >   
> не знаю, нужно мне это или нет, но incoming.alt у меня в .ssh/config нет 
> :) По историческим причинам там у меня другое имя прописано, и не вижу 
> причин начильственно приводить всех к одной гребенке :).

У меня там тоже другое написано.
Короче нахер не нужно.

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

Re: [devel] I: gear-tarimport

[Alexey I. Froloff]

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

* Mikhail Yakshin <greycat@> [070128 18:18]:
> > Если инструмент мне _диктует_ такие вещи -- он отправляется в /dev/null.
> > Даже без любых попыток тратить время на этот инструмент.
> Вот есть пакет, который filesystem.
Хреновый пример.

> Зачем иметь разные названия incoming.alt и git.alt, отличающиеся от 
> рекомендованных - я пока не могу придумать.
Рекомендованных, а не обязательных к использованию.

> Запуск "Sisyphus-setup" позволяет убедиться в том, что в
> конфиге ssh эти алиасы есть
Он это делает хреново.  Запись

Host devel.alt incoming.alt

, корректную с точки зрения ssh, он не поймёт.

> Опять же - если как в случае с cogito - если кто-то скажет, что ему 
> действительно нужно иначе - это все делается в 3 строчки, абсолютно 
> проблема.
Если скажешь номер стандарта, где явно сказано "incoming.alt" и
"MUST" - оставляй как есть.


Ты путаешь инструмент и область его применения.  "Этой дрелью
можно сверлить только северные и западные стены в полночь в
полнолуние".

-- 
Regards,
Sir Raorn.

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

Re: [devel] [flame] было про сomfort, стало про spt.

[Nick S. Grechukh]

2007/1/27, Denis Medvedev <a_mdl@mail.ru>:
> б) Назвать его как следующую версию spt, введя в заблуждение тех, кто думал что это действительно следующая версия.
> в) Поддерживать его в постоянно нерабочем состоянии.

прямщаз он кладет в full.cz пустой modules.dep, и afair именно этим
объясняется незагружаемость созданных им образов.

кстати, изкоробочный spt-0.4.0-alt2.1 тоже не совсем рабочий: в
full.cz отсутствуют init и stage1 потому что spt ищет LIBDIR по
getconf, которого нет в инструментальном чруте. пофиксил так:

--- spt.orig    2007-01-25 03:13:29 +0200
+++ spt 2007-01-25 04:36:57 +0200
@@ -312,7 +312,7 @@
 # make boot
 #
 # install init packages
-init_chroot_progs "mar propagator syslinux $KERNEL"
+init_chroot_progs "mar propagator syslinux glibc-utils $KERNEL"

 [ -d $outdir/isolinux/alt0 ] && rm -rf $outdir/isolinux/alt0
 mkdir -p $outdir/isolinux/alt0


не знаю, насколько это правильно концептуально, и что будет при
кросс-сборке i586 на x86_64 хосте. хотя с другой стороны, ведь mar и
gencpio так и запускаются.

Re: [devel] [flame] было про сomfort, стало про spt.

[Konstantin A. Lepikhov]

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

Hi Nick!

Sunday 28, at 07:05:43 PM you wrote:

> 2007/1/27, Denis Medvedev <a_mdl@mail.ru>:
> > б) Назвать его как следующую версию spt, введя в заблуждение тех, кто думал что это действительно следующая версия.
> > в) Поддерживать его в постоянно нерабочем состоянии.
> 
> прямщаз он кладет в full.cz пустой modules.dep, и afair именно этим
> объясняется незагружаемость созданных им образов.
берите spt из
http://git.altlinux.org/people/lakostis/packages/?p=spt.git;a=summary

> 
> кстати, изкоробочный spt-0.4.0-alt2.1 тоже не совсем рабочий: в
> full.cz отсутствуют init и stage1 потому что spt ищет LIBDIR по
> getconf, которого нет в инструментальном чруте. пофиксил так:
есть он там.

-- 
WBR et al.

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

Re: [devel] [flame] было про сomfort, стало про spt.

[Nick S. Grechukh]

2007/1/28, Konstantin A. Lepikhov <lakostis@altlinux.org>:
> Hi Nick!
> Sunday 28, at 07:05:43 PM you wrote:
> > прямщаз он кладет в full.cz пустой modules.dep, и afair именно этим
> > объясняется незагружаемость созданных им образов.

э, здесь spt3 mean

> берите spt из
> http://git.altlinux.org/people/lakostis/packages/?p=spt.git;a=summary
> >

а здесь уже spt
> > кстати, изкоробочный spt-0.4.0-alt2.1 тоже не совсем рабочий: в
> > full.cz отсутствуют init и stage1 потому что spt ищет LIBDIR по
> > getconf, которого нет в инструментальном чруте. пофиксил так:
> есть он там.

у меня не было, судя по мелькнувшему в выводе spt -vv. потом полез в
hsh-shell $workdir и долго искал. как сейчас в сизифе/git - не знаю.

Re: [devel] [flame] было про сomfort, стало про spt.

[Konstantin A. Lepikhov]

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

Hi Nick!

Sunday 28, at 09:28:04 PM you wrote:

> э, здесь spt3 mean
тогда не надо ссылаться на spt. Это совсем разные пакеты с разными багами
:)

-- 
WBR et al.

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

Re: [devel] [flame] было про сomfort, стало про spt.

[Nick S. Grechukh]

так весь спич и был про то, что spt и spt3 работают по очереди.

когда я поздней осенью интересовался - нормально работал только spt3.
сейчас наоборот.

2007/1/28, Konstantin A. Lepikhov <lakostis@altlinux.org>:
> Hi Nick!
>
> Sunday 28, at 09:28:04 PM you wrote:
>
> > э, здесь spt3 mean
> тогда не надо ссылаться на spt. Это совсем разные пакеты с разными багами
> :)
>
> --
> WBR et al.
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFFvP3S3TEpd8GO1nMRAradAJ96aneK6JnlcS3UOzCpaSREzfcyUgCeMD7f
> 23v36LH+kjKfhJlO7YSSXkw=
> =4Du0
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel
>

Re: [devel] [flame] было про сomfort, стало про spt.

[Konstantin A. Lepikhov]

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

Hi Nick!

Sunday 28, at 09:52:58 PM you wrote:

> так весь спич и был про то, что spt и spt3 работают по очереди.
> 
> когда я поздней осенью интересовался - нормально работал только spt3.
> сейчас наоборот.
spt - это пакет, которым собирают installer. Он не может не работать :)

-- 
WBR et al.

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

Re: [devel] [flame] было про сomfort , стало про spt.

[Hihin Ruslan]

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

Здравствуйте Konstantin A. Lepikhov
  В сообщении от Sunday 28 January 2007 21:48 Konstantin A. Lepikhov 
написал(a):
 > берите spt из
 > http://git.altlinux.org/people/lakostis/packages/?p=spt.git;a=summary
Ещё-бы хорошо иметь краткую инструкцию как и что брать по анонимному 
доступу.

-- 
С уважением Xихин Руслан

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

Re: [devel] [flame] было про сomfort , стало про spt.

[Konstantin A. Lepikhov]

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

Hi Hihin!

Sunday 28, at 11:11:56 PM you wrote:

> Здравствуйте Konstantin A. Lepikhov
>   В сообщении от Sunday 28 January 2007 21:48 Konstantin A. Lepikhov 
> написал(a):
>  > берите spt из
>  > http://git.altlinux.org/people/lakostis/packages/?p=spt.git;a=summary
> Ещё-бы хорошо иметь краткую инструкцию как и что брать по анонимному 
> доступу.
вам нужна краткая инструкция как пользоваться git??

-- 
WBR et al.

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

Re: [devel] I: gear-tarimport (habits)

[Michael Shigorin]

On Sun, Jan 28, 2007 at 06:13:33PM +0300, Mikhail Yakshin wrote:
> > MY> Если он у всех будет называться incoming.alt - разве это будет плохо?
> > Если инструмент мне _диктует_ такие вещи -- он отправляется в /dev/null.
> > Даже без любых попыток тратить время на этот инструмент.
> Вот есть пакет, который filesystem. Он _диктует_, что в системе
> должна быть директории, например /srv и /media. Он тоже в
> /dev/null без попыток тратить время?

Я бы их грохнул, но это тот случай, когда проще согласиться.

С алиасом incoming -- думаю, все всё поняли и так.

> Зачем иметь разные названия incoming.alt и git.alt,
> отличающиеся от рекомендованных - я пока не могу придумать.

Они могли врости в пальцы, в конце концов.  Некоторые их ещё
иногда набирают. :-)

Миш, в таких случаях проще соглашаться с привычками (лучше
их при этом предусматривать), чем пытаться ломать.  Даже если 
они ничего сами по себе не стоят или не приносят, это просто
много ненужного шума ни о чём.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] [flame] было про сomfort , стало про spt.

[Hihin Ruslan]

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

Здравствуйте Konstantin A. Lepikhov
  В сообщении от Sunday 28 January 2007 23:25 Konstantin A. Lepikhov 
написал(a):
 > вам нужна краткая инструкция как пользоваться git??
Нет - как по анонимному доступу скачать исходники к себе, хотя-бы в свой 
локальный git, что-бы потом разбираться.
-- 
С уважением Xихин Руслан

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

Re: [devel] I: gear-tarimport (habits)

[Alexey Tourbin]

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

On Sun, Jan 28, 2007 at 10:32:23PM +0200, Michael Shigorin wrote:
> > Зачем иметь разные названия incoming.alt и git.alt,
> > отличающиеся от рекомендованных - я пока не могу придумать.
> 
> Они могли врости в пальцы, в конце концов.  Некоторые их ещё
> иногда набирают. :-)

Вообще-то тот хост по DNS называется cvs.altlinux.org.
То что там есть каталог incoming ещё не значит что сам хост
надо называть incoming.  И вообще-то у нас сейчас три инкаминга.

В общем вкусовщина какая-то.

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

Re: [devel] [flame] было про сomfort , стало про spt.

[Denis Medvedev]

А отправить в сизиф какие проблемы? Хотя бы как sborshchik-sistemy-alt0.1
То меня к legion отправляют, то теперь к lacostis. У кого же сейчас рабочая версия spt?
-----Original Message-----
From: "Konstantin A. Lepikhov" <lakostis@altlinux.org>
To: ALT Devel discussion list <devel@lists.altlinux.org>
Date: Sun, 28 Jan 2007 23:25:52 +0300
Subject: Re: [devel][flame] было про сomfort , стало про spt.

> Hi Hihin!
> 
> Sunday 28, at 11:11:56 PM you wrote:
> 
> > Здравствуйте Konstantin A. Lepikhov
> >   В сообщении от Sunday 28 January 2007 21:48 Konstantin A. Lepikhov 
> > написал(a):
> >  > берите spt из
> >  > http://git.altlinux.org/people/lakostis/packages/?p=spt.git;a=summary
> > Ещё-бы хорошо иметь краткую инструкцию как и что брать по анонимному 
> > доступу.
> вам нужна краткая инструкция как пользоваться git??
> 
> -- 
> WBR et al.
> 
> ATTACHMENT: application/pgp-signature (signature.asc)
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] [flame] было про сomfort , стало про spt.

[Konstantin A. Lepikhov]

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

Hi Hihin!

Monday 29, at 12:03:56 AM you wrote:

> Здравствуйте Konstantin A. Lepikhov
>   В сообщении от Sunday 28 January 2007 23:25 Konstantin A. Lepikhov 
> написал(a):
>  > вам нужна краткая инструкция как пользоваться git??
> Нет - как по анонимному доступу скачать исходники к себе, хотя-бы в свой 
> локальный git, что-бы потом разбираться.
а чем наш git отличается от других? git pull
http://git.altlinux.org/people/lakostis/packages/spt.git

PS AFAIR, вместо http:// можно смело использовать git://

-- 
WBR et al.

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

Re: [devel] [flame] было про сomfort , стало про spt.

[Konstantin A. Lepikhov]

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

Hi Denis!

Monday 29, at 12:28:55 AM you wrote:

> 
> А отправить в сизиф какие проблемы? Хотя бы как sborshchik-sistemy-alt0.1
> То меня к legion отправляют, то теперь к lacostis. У кого же сейчас рабочая версия spt?
А вот взять и почитать тред на wiki.freesource.info -
http://wiki.sisyphus.ru/devel/installer/iso?v=ipq

PS lakostis@ уже написал инструкцию к spt, она уже есть в 0.5.0.

-- 
WBR et al.

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

Re: [devel] I: gear-tarimport

[Kirill A. Shutemov]

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

On [Sun, 28.01.2007 18:13], Mikhail Yakshin wrote:
> Есть инструмент, который git.altlinux.org - он, как ни тресни, имеет 
> хостнейм git.altlinux.org - и он тоже _диктует_, что . Его тоже?

# echo '$(host git.altlinux.org|cut -d ' ' -f 4)
	another.hostname.for.git.velesys.com' >> /etc/hosts
# ping another.hostname.for.git.velesys.com
PING another.hostname.for.git.velesys.com (217.16.24.12) 56(84) bytes of
data.
64 bytes from another.hostname.for.git.velesys.com (217.16.24.12):
icmp_seq=1 ttl=52 time=93.4 ms

> Есть инструмент, который, например, ssh - он кладет конфиги пользователя 
> в ~/.ssh и почему-то мало кто возражает.
man 1 ssh:
  -F configfile
             Specifies an alternative per-user configuration file.  If a con-
             figuration file is given on the command line, the system-wide
             configuration file (/etc/openssh/ssh_config) will be ignored.
             The default for the per-user configuration file is
             $HOME/.ssh/config.


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

Re: [devel] [flame] было про сomfort , стало про spt.

[Hihin Ruslan]

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

Здравствуйте Konstantin A. Lepikhov
  В сообщении от Monday 29 January 2007 00:29 Konstantin A. Lepikhov 
написал(a):
 > а чем наш git отличается от других? 
 > git pull http://git.altlinux.org/people/lakostis/packages/spt.git
>PS AFAIR, вместо http:// можно смело использовать git://

Спасибо !
Сразу и скачал :)

-- 
С уважением Xихин Руслан

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

Re: [devel] [flame] было про сomfort , стало про spt.

[Denis Medvedev]

Спасибо, теперь все ясно.

-----Original Message-----
From: "Konstantin A. Lepikhov" <lakostis@altlinux.org>
To: ALT Devel discussion list <devel@lists.altlinux.org>
Date: Mon, 29 Jan 2007 00:41:12 +0300
Subject: Re: [devel][flame] было про сomfort , стало про spt.

> Hi Denis!
> 
> Monday 29, at 12:28:55 AM you wrote:
> 
> > 
> > А отправить в сизиф какие проблемы? Хотя бы как sborshchik-sistemy-alt0.1
> > То меня к legion отправляют, то теперь к lacostis. У кого же сейчас рабочая версия spt?
> А вот взять и почитать тред на wiki.freesource.info -
> http://wiki.sisyphus.ru/devel/installer/iso?v=ipq
> 
> PS lakostis@ уже написал инструкцию к spt, она уже есть в 0.5.0.
> 
> -- 
> WBR et al.
> 
> ATTACHMENT: application/pgp-signature (signature.asc)
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] mkmar

[Dmitry V. Levin]

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

On Sun, Jan 28, 2007 at 07:05:43PM +0200, Nick S. Grechukh wrote:
> 2007/1/27, Denis Medvedev <a_mdl@mail.ru>:
> > б) Назвать его как следующую версию spt, введя в заблуждение тех, кто думал что это действительно следующая версия.
> > в) Поддерживать его в постоянно нерабочем состоянии.
> 
> прямщаз он кладет в full.cz пустой modules.dep, и afair именно этим
> объясняется незагружаемость созданных им образов.

Это regression в mkmar, теперь без опции -r он работает неправильно.


-- 
ldv

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

Re: [devel] I: gear-tarimport

[Денис Смирнов]

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

On Sun, Jan 28, 2007 at 06:13:33PM +0300, Mikhail Yakshin wrote:

>> Если инструмент мне _диктует_ такие вещи -- он отправляется в /dev/null.
>> Даже без любых попыток тратить время на этот инструмент.
MY> Вот есть пакет, который filesystem. Он _диктует_, что в системе должна 
MY> быть директории, например /srv и /media. Он тоже в /dev/null без попыток 
MY> тратить время?

Увы, нет. Потому что это FHS. Один из немногих стандартов которые принято
все-таки хотя бы пытаться соблюдать (несмотря на то, что я считаю что
кое-что там явно писали с перепою).

MY> Есть инструмент, который git.altlinux.org - он, как ни тресни, имеет 
MY> хостнейм git.altlinux.org - и он тоже _диктует_, что . Его тоже?

Его -- не то же. А вот alias, который человек прописывает себе для
удобство -- звиняйте, святое право каждого придумывать себе алиасы как ему
заблагорассудится.

MY> Есть инструмент, который, например, ssh - он кладет конфиги пользователя 
MY> в ~/.ssh и почему-то мало кто возражает.

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

MY> В пакете есть user-defined опции типа $GIT_HOME_DIR или $BUILD_DIR, их, 
MY> по-моему, имеет смысл переопределять - в эти директории люди ходят 
MY> руками, набирают "cd что-нибудь" - тут есть вопрос в 
MY> удобстве-неудобстве, кому какое имя нравится и приятно видеть. В конце 
MY> концов, директории полезно иметь переопределяемыми, чтобы перенести их 
MY> на другие файловые системы, какой-нибудь /srv/development, который лежит 
MY> где-нибудь аж нелокально.

Безусловно.

MY> Зачем иметь разные названия incoming.alt и git.alt, отличающиеся от 
MY> рекомендованных - я пока не могу придумать. Запуск "Sisyphus-setup" 
MY> позволяет убедиться в том, что в конфиге ssh эти алиасы есть и позволяет 
MY> за ними не следить. В идеале - вручную набирать где-либо incoming.alt и 
MY> git.alt не должно быть нужно - мейнтейнер вообще может о них ничего не 
MY> знать.

Потому что мне неудобно набирать incoming.alt. А значит набирать я это не
буду. git.alt -- да, у меня так и называется. Потому как коротко. А вот
incoming у меня называется devel. Потому как мне так набирать быстрее. А
я, блин, злостный лентяй который лишнюю буковку на клаве набирать не
будет.

MY> Опять же - если как в случае с cogito - если кто-то скажет, что ему 
MY> действительно нужно иначе - это все делается в 3 строчки, абсолютно 
MY> проблема.

Тогда лучше пофикси :) Кстати глянь на seiros-build-utils (у меня в git),
возможно оттуда часть имеет смысл перетащить в comfort. Я бы предпочел
чтобы был один пакет содержащий общий функционал, и группа пакетов со
вкусовщиной. Там все написано совсем мерзко, потому как лично под меня. И
со странными именами, потому что мне они удобны. Но alias'ы всяко написать
каждый может. А скажем утилитка Co, что у меня лежит, ой как мне жизню
облегчает. Аналогично небесполезная утилитка ptch. gear-svnupdate мне тоже
частенько помогает. 

Скрипты Add и Mv я когда-нибудь все-таки заточу под git (сейчас это чисто
для svn)

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

http://freesource.info
----------------------------------------------------------------------------
В принципе можно сделать все.  На практике интересно то, что уже
есть.
		-- mike in devel@

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

Re: [devel] I: gear-tarimport

[Mikhail Yakshin]

Относительно всей дискуссии об alias'ах ssh - всем спасибо, тема закрыта:

http://git.altlinux.org/people/greycat/packages/?p=comfort.git;a=commit;h=bf79a81329fc0a95b2979c259e1034cc43c8d3a0

Переменные INCOMING_ALT_HOST и GIT_ALT_HOST. В примере ~/.Sisyphusrc есть.

Денис Смирнов wrote:
> MY> Есть инструмент, который, например, ssh - он кладет конфиги
> пользователя MY> в ~/.ssh и почему-то мало кто возражает.
> 
> Я возражаю. Я вообще считаю дурную практику класть конфиги в ~/, а не
> в ~/.etc издевательством. Но, увы, мое мнение явно в меньшинстве,
> потому приходится терпеть это свинство.

Можно пример хотя бы 5 пакетов, которые кладут что-то в ~/.etc? Имеет
смысл такой практики придерживаться для comfort?

> MY> Зачем иметь разные названия incoming.alt и git.alt, отличающиеся
> от MY> рекомендованных - я пока не могу придумать. Запуск
> "Sisyphus-setup" MY> позволяет убедиться в том, что в конфиге ssh эти
> алиасы есть и позволяет MY> за ними не следить. В идеале - вручную
> набирать где-либо incoming.alt и MY> git.alt не должно быть нужно -
> мейнтейнер вообще может о них ничего не MY> знать.
> 
> Потому что мне неудобно набирать incoming.alt. А значит набирать я
> это не буду. git.alt -- да, у меня так и называется. Потому как
> коротко. А вот incoming у меня называется devel. Потому как мне так
> набирать быстрее. А я, блин, злостный лентяй который лишнюю буковку
> на клаве набирать не будет.

Можно поинтересоваться - с совершенно честными и ясными глазами? Я,
наверное, глупый, про git.alt я примерно понимаю еще, как с ним можно
работать руками, но какие операции вручную можно делать с incoming.alt?

Заливка релизов - для этого есть уже с десяток разных скриптов, в
comfort есть десяток+первый. Правка ACL - думаю, опять же, лучше
довылизывать Sisyphus-acl до состояния, когда бы он всех удовлетворял,
чем делать руками "2 rsync туда-обратно + редактирование файла +
поискать на вики, где было описание формата этих файлов, потому что
формат уже забылся", нет?

На ум приходит только всякие операции типа убирания пакетов из incoming
(rsync с /var/empty) - но, во-первых, это довольно редкие операции,
во-вторых, скоро все этого в любом случае не будет, если будет переезд
на тотальный git...

Просмотр списка файлов в incoming и скачивание чего-либо оттуда, пока
оно еще не попало в Сизиф - исчезающе редкая операция, скорее всего то
же самое все лежит у мейнтейнера в git, даже более свежее...

Я все-таки что-то упустил?

> Кстати глянь на seiros-build-utils (у меня в git), возможно оттуда
> часть имеет смысл перетащить в comfort. Я бы предпочел чтобы был один
> пакет содержащий общий функционал, и группа пакетов со вкусовщиной.
> Там все написано совсем мерзко, потому как лично под меня. И со
> странными именами, потому что мне они удобны. Но alias'ы всяко
> написать каждый может. А скажем утилитка Co, что у меня лежит, ой как
> мне жизню облегчает. Аналогично небесполезная утилитка ptch.
> gear-svnupdate мне тоже частенько помогает. Скрипты Add и Mv я
> когда-нибудь все-таки заточу под git (сейчас это чисто для svn)

Посмотрел, спасибо, я раньше не знал о существовании этого пакета. Там
есть масса полезных вещей (например, gear-rel, svn-update, gi,
git-repos-cleanup, send-devel, pkg_release, sisyphus-list-incoming - они
все по образу действия по-моему достаточно близки к comfort и хотелось
бы их действительно по возможности объединить туда).

Относительно некоторых утилит - мне с первого взгляда оказалось не
очевидным, что они делают %)

Co - это (псевдо)графическая выбиралка и переключалка между бранчами?

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

ptch_filter - один из самых интересных, по идее, скриптов - он как-то
хитро фильтрует патчи - но как - я с первого взгляда не понял.

Что *именно* делают Add и Mv, кроме наиболее общих "добавляют все, что
не добавлено" и "перемещают все массово из одного места в другое" с
пустыми commit messages - я так и не понял? Update - зачем там делаются
эти хитрые chmod'ы?

В перспективе - мне хотелось бы еще поговорить с lav@ насчет
etersoft-build-utils - т.к. там масса наработок по сборке пакетов и
абсолютно не хочется дублировать эту функциональность в comfort, набивая
все те же самые грабли, что уже наметили на карте добрые люди и
изобретать велосипед (особенно впечатляет там сборка из одного ALT'ового
spec в кучу дистрибутивов). В идеале - хотелось бы интегрироваться в ту
или другую сторону, т.к. я умышленно сейчас в comfort делал сборку
пакетов в очень минимальном виде, а в etersoft-build-utils нет некоего
workflow для git. Вместе получилось бы хорошо.

-- 
WBR, Mikhail Yakshin AKA GreyCat
ALT Linux [http://www.altlinux.ru] [xmpp:greycat@altlinux.org]

Re: [devel] I: gear-tarimport

[Alexey Tourbin]

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

On Mon, Jan 29, 2007 at 11:27:40PM +0300, Mikhail Yakshin wrote:
> > Я возражаю. Я вообще считаю дурную практику класть конфиги в ~/, а не
> > в ~/.etc издевательством. Но, увы, мое мнение явно в меньшинстве,
> > потому приходится терпеть это свинство.
> 
> Можно пример хотя бы 5 пакетов, которые кладут что-то в ~/.etc? Имеет
> смысл такой практики придерживаться для comfort?

В PLD пропатчили довольно много пакетов на предмет использования ~/etc
для дот-файлов.

> > MY> Зачем иметь разные названия incoming.alt и git.alt, отличающиеся
> > от MY> рекомендованных - я пока не могу придумать. Запуск
> > "Sisyphus-setup" MY> позволяет убедиться в том, что в конфиге ssh эти
> > алиасы есть и позволяет MY> за ними не следить. В идеале - вручную
> > набирать где-либо incoming.alt и MY> git.alt не должно быть нужно -
> > мейнтейнер вообще может о них ничего не MY> знать.
> > 
> > Потому что мне неудобно набирать incoming.alt. А значит набирать я
> > это не буду. git.alt -- да, у меня так и называется. Потому как
> > коротко. А вот incoming у меня называется devel. Потому как мне так
> > набирать быстрее. А я, блин, злостный лентяй который лишнюю буковку
> > на клаве набирать не будет.
> 
> Можно поинтересоваться - с совершенно честными и ясными глазами? Я,
> наверное, глупый, про git.alt я примерно понимаю еще, как с ним можно
> работать руками, но какие операции вручную можно делать с incoming.alt?

Я все пакеты вручную заливаю, у меня никаких скриптов нет.  Выходит
довольно быстро.  Просто научился нажимать ^R в zsh.  И ещё некоторые
сочетания кнопок научился нажимать в zsh, так что необходимость во
всяких там маленьких скриптах почти отпала.  Лимит на ~/.zsh_history
увеличил, да.

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

Re: [devel] I: gear-tarimport

[Mikhail Yakshin]

Alexey Tourbin wrote:
> On Mon, Jan 29, 2007 at 11:27:40PM +0300, Mikhail Yakshin wrote:
>>> Я возражаю. Я вообще считаю дурную практику класть конфиги в ~/, а не
>>> в ~/.etc издевательством. Но, увы, мое мнение явно в меньшинстве,
>>> потому приходится терпеть это свинство.
>> Можно пример хотя бы 5 пакетов, которые кладут что-то в ~/.etc? Имеет
>> смысл такой практики придерживаться для comfort?
> 
> В PLD пропатчили довольно много пакетов на предмет использования ~/etc
> для дот-файлов.

Понятно, спасибо. Все-таки мнение общественности - где нам стоит держать
user-wide конфиги?

>> Можно поинтересоваться - с совершенно честными и ясными глазами? Я,
>> наверное, глупый, про git.alt я примерно понимаю еще, как с ним можно
>> работать руками, но какие операции вручную можно делать с incoming.alt?
> 
> Я все пакеты вручную заливаю, у меня никаких скриптов нет.  Выходит
> довольно быстро.  Просто научился нажимать ^R в zsh.  И ещё некоторые
> сочетания кнопок научился нажимать в zsh, так что необходимость во
> всяких там маленьких скриптах почти отпала.  Лимит на ~/.zsh_history
> увеличил, да.

Понятно, тоже хороший вариант, если он позволяет быстро и продуктивно
решать задачи. Но в таком случае тот, кто работает в основном через ^R,
очевидно, не будет пользоваться всем пакетом comfort (или ему подобным)
целиком.

-- 
WBR, Mikhail Yakshin AKA GreyCat
ALT Linux [http://www.altlinux.ru] [xmpp:greycat@altlinux.org]

Re: [devel] I: gear-tarimport

[Eugene Ostapets]

29.01.07, Mikhail Yakshin<greycat altlinux.org> написал(а):
> Alexey Tourbin wrote:
> > On Mon, Jan 29, 2007 at 11:27:40PM +0300, Mikhail Yakshin wrote:
> >>> Я возражаю. Я вообще считаю дурную практику класть конфиги в ~/, а не
> >>> в ~/.etc издевательством. Но, увы, мое мнение явно в меньшинстве,
> >>> потому приходится терпеть это свинство.
> >> Можно пример хотя бы 5 пакетов, которые кладут что-то в ~/.etc? Имеет
> >> смысл такой практики придерживаться для comfort?
> >
> > В PLD пропатчили довольно много пакетов на предмет использования ~/etc
> > для дот-файлов.
>
> Понятно, спасибо. Все-таки мнение общественности - где нам стоит держать
> user-wide конфиги?
Было бы здорово в ~/.etc

-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [devel] I: gear-tarimport

[Alexey Tourbin]

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

On Mon, Jan 29, 2007 at 11:45:48PM +0200, Eugene Ostapets wrote:
> 29.01.07, Mikhail Yakshin<greycat altlinux.org> написал(а):
> > Alexey Tourbin wrote:
> > > On Mon, Jan 29, 2007 at 11:27:40PM +0300, Mikhail Yakshin wrote:
> > >>> Я возражаю. Я вообще считаю дурную практику класть конфиги в ~/, а не
> > >>> в ~/.etc издевательством. Но, увы, мое мнение явно в меньшинстве,
> > >>> потому приходится терпеть это свинство.
> > >> Можно пример хотя бы 5 пакетов, которые кладут что-то в ~/.etc? Имеет
> > >> смысл такой практики придерживаться для comfort?
> > >
> > > В PLD пропатчили довольно много пакетов на предмет использования ~/etc
> > > для дот-файлов.
> >
> > Понятно, спасибо. Все-таки мнение общественности - где нам стоит держать
> > user-wide конфиги?
> Было бы здорово в ~/.etc

По-моему не стоит.  Если хотя бы половина приложений использовало
специальный каталог для dotfiles, тогда было бы к чему стремиться.
А так от того что пара пакетов будет использовать ~/.etc/$name вместо
~/.$name бардака меньше не станет.

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

Re: [devel] I: gear-tarimport

[Eugene Ostapets]

29.01.07, Alexey Tourbin<at altlinux.ru> написал(а):
> On Mon, Jan 29, 2007 at 11:45:48PM +0200, Eugene Ostapets wrote:
> > 29.01.07, Mikhail Yakshin<greycat altlinux.org> написал(а):
> > > Alexey Tourbin wrote:
> > > > On Mon, Jan 29, 2007 at 11:27:40PM +0300, Mikhail Yakshin wrote:
> > > >>> Я возражаю. Я вообще считаю дурную практику класть конфиги в ~/, а не
> > > >>> в ~/.etc издевательством. Но, увы, мое мнение явно в меньшинстве,
> > > >>> потому приходится терпеть это свинство.
> > > >> Можно пример хотя бы 5 пакетов, которые кладут что-то в ~/.etc? Имеет
> > > >> смысл такой практики придерживаться для comfort?
> > > >
> > > > В PLD пропатчили довольно много пакетов на предмет использования ~/etc
> > > > для дот-файлов.
> > >
> > > Понятно, спасибо. Все-таки мнение общественности - где нам стоит держать
> > > user-wide конфиги?
> > Было бы здорово в ~/.etc
>
> По-моему не стоит.  Если хотя бы половина приложений использовало
> специальный каталог для dotfiles, тогда было бы к чему стремиться.
> А так от того что пара пакетов будет использовать ~/.etc/$name вместо
> ~/.$name бардака меньше не станет.
Так уже используют... ~/.config, ~/.local... Бардака стало меньше...
Нужно продолжить начинание :)

-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [devel] I: gear-tarimport

[Alexey I. Froloff]

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

* Eugene Ostapets <eostapets@> [070130 01:03]:
> > А так от того что пара пакетов будет использовать ~/.etc/$name вместо
> > ~/.$name бардака меньше не станет.
> Так уже используют... ~/.config, ~/.local... Бардака стало меньше...
> Нужно продолжить начинание :)
См.
http://standards.freedesktop.org/basedir-spec/latest/ar01s03.html

$XDG_CONFIG_HOME с фолбэком в ~/.congig/

-- 
Regards,
Sir Raorn.

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

Re: [devel] I: gear-tarimport

[Andrey Rahmatullin]

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

On Tue, Jan 30, 2007 at 01:58:45AM +0300, Alexey I. Froloff wrote:
> См.
> http://standards.freedesktop.org/basedir-spec/latest/ar01s03.html
> 
> $XDG_CONFIG_HOME с фолбэком в ~/.congig/
+1

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

(сейчас меня кунут, но что делать)
		-- mike in devel@

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

Re: [devel] I: gear-tarimport

[Денис Смирнов]

[-- 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 --]

Re: [devel] I: gear-tarimport

[Денис Смирнов]

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

On Mon, Jan 29, 2007 at 11:35:06PM +0300, Алексей Турбин wrote:

>> Можно пример хотя бы 5 пакетов, которые кладут что-то в ~/.etc? Имеет
>> смысл такой практики придерживаться для comfort?
AT> В PLD пропатчили довольно много пакетов на предмет использования ~/etc
AT> для дот-файлов.

Круто. Только .etc было бы, наверное, правильнее.

>> Можно поинтересоваться - с совершенно честными и ясными глазами? Я,
>> наверное, глупый, про git.alt я примерно понимаю еще, как с ним можно
>> работать руками, но какие операции вручную можно делать с incoming.alt?
AT> Я все пакеты вручную заливаю, у меня никаких скриптов нет.  Выходит
AT> довольно быстро.  Просто научился нажимать ^R в zsh.  И ещё некоторые
AT> сочетания кнопок научился нажимать в zsh, так что необходимость во
AT> всяких там маленьких скриптах почти отпала.  Лимит на ~/.zsh_history
AT> увеличил, да.

:)

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

http://freesource.info
----------------------------------------------------------------------------
Есть ли ещё вопросы к защите или считать заседание закрытым?
		-- lav in #4488

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

Re: [devel] I: gear-tarimport

[Денис Смирнов]

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

On Tue, Jan 30, 2007 at 12:32:50AM +0300, Mikhail Yakshin wrote:

>> В PLD пропатчили довольно много пакетов на предмет использования ~/etc
>> для дот-файлов.
MY> Понятно, спасибо. Все-таки мнение общественности - где нам стоит держать
MY> user-wide конфиги?

Когда количество приложений большое -- в существовании ~/.?etc имеется
большой смысл. Так же как, IMHO, в ~/var/{cache,spool}, например. Тот же
процесс бэкапа становится куда проще. Или можно конфиги в SCM какую
положить :)

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

http://freesource.info
----------------------------------------------------------------------------
> В системе установлен kudzu ?
Конечно да. Какое хайку без кудзы? :)
		-- avp in sisyphus@

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

Re: [devel] I: gear-tarimport

[Денис Смирнов]

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

On Tue, Jan 30, 2007 at 12:56:53AM +0300, Алексей Турбин wrote:

AT> По-моему не стоит.  Если хотя бы половина приложений использовало
AT> специальный каталог для dotfiles, тогда было бы к чему стремиться.
AT> А так от того что пара пакетов будет использовать ~/.etc/$name вместо
AT> ~/.$name бардака меньше не станет.

Если хотя бы десяток из установленых у тебя приложений будут смотреть в
.etc, это уже облегчит жизнь.

А у меня сейчас в ~/ 92 dotfile. И меня это, честно говоря, ой как
напрягает. dotfiles -- зло.

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

http://freesource.info
----------------------------------------------------------------------------
>       Какая разница между %configure и ./configure ?..
rpm --eval %configure
		-- wrar in community@

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

Re: [devel] I: gear-tarimport

[Денис Смирнов]

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

On Tue, Jan 30, 2007 at 01:58:45AM +0300, Alexey I. Froloff wrote:

> >> А так от того что пара пакетов будет использовать ~/.etc/$name вместо
> >> ~/.$name бардака меньше не станет.
>> Так уже используют... ~/.config, ~/.local... Бардака стало меньше...
>> Нужно продолжить начинание :)
AIF> См.
AIF> http://standards.freedesktop.org/basedir-spec/latest/ar01s03.html
AIF> $XDG_CONFIG_HOME с фолбэком в ~/.congig/

То что надо! А либа какая-нибудь простая для этого есть? А то получается
ой как много хоть и простого, но дублирующегося в разных пакетах кода
(если мы начнем патчить все что под руку попадется для поддержки этого
стандарта)?

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

http://freesource.info
----------------------------------------------------------------------------
У меня нет желания тренироваться на кошках.
		-- ldv in devel@

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

Re: [devel] I: gear-tarimport

[Led]

В сообщении от 30 января 2007 13:55 Денис Смирнов написал(a):
> On Mon, Jan 29, 2007 at 11:27:40PM +0300, Mikhail Yakshin wrote:
> >> Я возражаю. Я вообще считаю дурную практику класть конфиги в ~/, а не
> >> в ~/.etc издевательством. Но, увы, мое мнение явно в меньшинстве,
> >> потому приходится терпеть это свинство.
>
> MY> Можно пример хотя бы 5 пакетов, которые кладут что-то в ~/.etc? Имеет
> MY> смысл такой практики придерживаться для comfort?
>
> Ни одного. Поэтому не имеет. Хотя это и было бы гораздо удобнее.

И не будет IMHO, пока ~/.etc нет в etcskel

-- 
Led.

Re: [devel] I: gear-tarimport

[Led]

В сообщении от 30 января 2007 13:55 Денис Смирнов написал(a):
> On Mon, Jan 29, 2007 at 11:35:06PM +0300, Алексей Турбин wrote:
> >> Можно пример хотя бы 5 пакетов, которые кладут что-то в ~/.etc? Имеет
> >> смысл такой практики придерживаться для comfort?
>
> AT> В PLD пропатчили довольно много пакетов на предмет использования ~/etc
> AT> для дот-файлов.
>
> Круто. Только .etc было бы, наверное, правильнее.

Неплохо бы определиться. А после этого завести в etcskel и ~/etc, и ~/.etc, 
один из которых - софт-линк на второй

-- 
Led.

Re: [devel] I: gear-tarimport

[Денис Смирнов]

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

On Tue, Jan 30, 2007 at 02:06:48PM +0200, Led wrote:

L> Неплохо бы определиться. А после этого завести в etcskel и ~/etc, и ~/.etc, 
L> один из которых - софт-линк на второй

А вот это нафиг. Цель убрать мусор из ~/, а не разводить его там :)

Раз уже есть стандарт, то лучше если это будет .config даже. Психи вроде
меня смогут сами переименовать, и переменную окружения поставить как
заблагорассудится. Хотя ".Фигня" обозвать.

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

http://freesource.info
----------------------------------------------------------------------------
<Hiddenman> блин, маздай: пришел, а у меня screensaver в виде kernel
            panic.....испугался и удивился ;)

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

Re: [devel] I: gear-tarimport

[Led]

В сообщении от 30 января 2007 14:16 Денис Смирнов написал(a):
> On Tue, Jan 30, 2007 at 02:06:48PM +0200, Led wrote:
>
> L> Неплохо бы определиться. А после этого завести в etcskel и ~/etc, и
> ~/.etc, L> один из которых - софт-линк на второй
>
> А вот это нафиг. Цель убрать мусор из ~/, а не разводить его там :)
>
> Раз уже есть стандарт, то лучше если это будет .config даже.

Ну раз есть стандарт - тогда без вопросов:) Но фичреквест на etcskel нужен?

> Психи вроде 
> меня смогут сами переименовать, и переменную окружения поставить как
> заблагорассудится. Хотя ".Фигня" обозвать.

-- 
Led.

Re: [devel] I: gear-tarimport

[Денис Смирнов]

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

On Tue, Jan 30, 2007 at 02:43:49PM +0200, Led wrote:

L> Ну раз есть стандарт - тогда без вопросов:) Но фичреквест на etcskel нужен?

А кто такие etcskel team, которые пакуют etcskel? Кстати в git, если
верить find-package, его нет.

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

http://freesource.info
----------------------------------------------------------------------------
ЗАКОН МАЙЛСА
 Угол зрения зависит от занимаемого места.

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

Re: [devel] I: gear-tarimport

[Dmitry V. Levin]

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

On Tue, Jan 30, 2007 at 10:55:27PM +0300, Денис Смирнов wrote:
> On Tue, Jan 30, 2007 at 02:43:49PM +0200, Led wrote:
> 
> L> Ну раз есть стандарт - тогда без вопросов:) Но фичреквест на etcskel нужен?
> 
> А кто такие etcskel team, которые пакуют etcskel?

grep -w etcskel Sisyphus/files/list/list.src.classic

> Кстати в git, если верить find-package, его нет.

find-package можно верить :)


-- 
ldv

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

[devel] ~/.config/ (was gear-tarimport)

[Led]

В сообщении от 30 января 2007 21:55 Денис Смирнов написал(a):
> On Tue, Jan 30, 2007 at 02:43:49PM +0200, Led wrote:
>
> L> Ну раз есть стандарт - тогда без вопросов:) Но фичреквест на etcskel
> нужен?
>
> А кто такие etcskel team, которые пакуют etcskel? Кстати в git, если
> верить find-package, его нет.

в случае нахождения пользовательских конфигов в ~/.config/ следует ли убирать 
из имени файлов/каталогов этих конфигов начальную точку?

-- 
Led.

Re: [devel] ~/.config/ (was gear-tarimport)

[Eugene Ostapets]

31.01.07, Led<led altlinux.ru> написал(а):
> В сообщении от 30 января 2007 21:55 Денис Смирнов написал(a):
> > On Tue, Jan 30, 2007 at 02:43:49PM +0200, Led wrote:
> >
> > L> Ну раз есть стандарт - тогда без вопросов:) Но фичреквест на etcskel
> > нужен?
> > А кто такие etcskel team, которые пакуют etcskel? Кстати в git, если
> > верить find-package, его нет.
> в случае нахождения пользовательских конфигов в ~/.config/ следует ли убирать
> из имени файлов/каталогов этих конфигов начальную точку?
Да, очень желательно, тогда все конфигурационные каталоги будут видны
в выводе просто ls, а также в mc при скрытии показа dotfiles

-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [devel] I: gear-tarimport

[Mikhail Yakshin]

Led пишет:
> В сообщении от 30 января 2007 14:16 Денис Смирнов написал(a):
>> On Tue, Jan 30, 2007 at 02:06:48PM +0200, Led wrote:
>>
>> L> Неплохо бы определиться. А после этого завести в etcskel и ~/etc, и
>> ~/.etc, L> один из которых - софт-линк на второй
>>
>> А вот это нафиг. Цель убрать мусор из ~/, а не разводить его там :)
>>
>> Раз уже есть стандарт, то лучше если это будет .config даже.
> 
> Ну раз есть стандарт - тогда без вопросов:) Но фичреквест на etcskel нужен?

https://bugzilla.altlinux.org/show_bug.cgi?id=10746

В comfort исправлю путь к конфигу в ближайшее время. Может быть повесим 
аналогичные FR на хотя бы наш in-house софт, вроде hasher, gear и т.п.

-- 
WBR, Mikhail Yakshin AKA GreyCat

Re: [devel] ~/.config/ (was gear-tarimport)

[Mikhail Yakshin]

Eugene Ostapets пишет:
> 31.01.07, Led<led altlinux.ru> написал(а):
>> В сообщении от 30 января 2007 21:55 Денис Смирнов написал(a):
>>> On Tue, Jan 30, 2007 at 02:43:49PM +0200, Led wrote:
>>>
>>> L> Ну раз есть стандарт - тогда без вопросов:) Но фичреквест на etcskel
>>> нужен?
>>> А кто такие etcskel team, которые пакуют etcskel? Кстати в git, если
>>> верить find-package, его нет.
>> в случае нахождения пользовательских конфигов в ~/.config/ следует ли убирать
>> из имени файлов/каталогов этих конфигов начальную точку?
> Да, очень желательно, тогда все конфигурационные каталоги будут видны
> в выводе просто ls, а также в mc при скрытии показа dotfiles

Ну, тогда, видимо, я сделаю ~/.config/Sisyphusrc, хорошо?

-- 
WBR, Mikhail Yakshin AKA GreyCat

Re: [devel] ~/.config/ (was gear-tarimport)

[Eugene Ostapets]

31.01.07, Mikhail Yakshin<greycat altlinux.org> написал(а):
> >> в случае нахождения пользовательских конфигов в ~/.config/ следует ли убирать
> >> из имени файлов/каталогов этих конфигов начальную точку?
> > Да, очень желательно, тогда все конфигурационные каталоги будут видны
> > в выводе просто ls, а также в mc при скрытии показа dotfiles
> Ну, тогда, видимо, я сделаю ~/.config/Sisyphusrc, хорошо?
Это будет замечательно! :)

-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [devel] ~/.config/ (was gear-tarimport)

[Led]

В сообщении от 31 января 2007 11:22 Eugene Ostapets написал(a):
> 31.01.07, Led<led altlinux.ru> написал(а):
> > В сообщении от 30 января 2007 21:55 Денис Смирнов написал(a):
> > > On Tue, Jan 30, 2007 at 02:43:49PM +0200, Led wrote:
> > >
> > > L> Ну раз есть стандарт - тогда без вопросов:) Но фичреквест на etcskel
> > > нужен?
> > > А кто такие etcskel team, которые пакуют etcskel? Кстати в git, если
> > > верить find-package, его нет.
> >
> > в случае нахождения пользовательских конфигов в ~/.config/ следует ли
> > убирать из имени файлов/каталогов этих конфигов начальную точку?
>
> Да, очень желательно, тогда все конфигурационные каталоги будут видны
> в выводе просто ls, а также в mc при скрытии показа dotfiles

Тогда ждать появления .config в etcskel или предусматривать в программах 
создание не только ~/.config/someprg.conf, а и самого ~/.config ?

-- 
Led.

Re: [devel] I: gear-tarimport

[Mikhail Gusarov]

Twas brillig at 12:33:42 when Mikhail Yakshin did gyre and gimble:

 MY> В comfort исправлю путь к конфигу в ближайшее время. Может быть
 MY> повесим аналогичные FR на хотя бы наш in-house софт, вроде
 MY> hasher, gear и т.п.

А вот на внешний софт вешать - не стоит, для совместимости. А уж если
что и делать, то уговаривать upstream, чтобы они дописали код для
переноса конфигов из старого места.

-- 

Re: [devel] ~/.config/ (was gear-tarimport)

[Damir Shayhutdinov]

> Тогда ждать появления .config в etcskel или предусматривать в программах
> создание не только ~/.config/someprg.conf, а и самого ~/.config ?

Господа, а вы уверены, что стоит заниматься этим во время фриза?

P.S. не пользуюсь mc, поэтому наличие и количество dotfiles в хомяке
меня никак не задевает. А вот миграцию с других дистрибутивов
введением ~/.config можно запросто осложнить.

Re: [devel] ~/.config/ (was gear-tarimport)

[Eugene Ostapets]

31.01.07, Led<led altlinux.ru> написал(а):
> > Да, очень желательно, тогда все конфигурационные каталоги будут видны
> > в выводе просто ls, а также в mc при скрытии показа dotfiles
> Тогда ждать появления .config в etcskel или предусматривать в программах
> создание не только ~/.config/someprg.conf, а и самого ~/.config ?
Создавать самостоятельно, если его нет...

-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [devel] I: gear-tarimport

[Mikhail Gusarov]

Twas brillig at 12:33:42 when Mikhail Yakshin did gyre and gimble:

 MY> В comfort исправлю путь к конфигу в ближайшее время. Может быть
 MY> повесим аналогичные FR на хотя бы наш in-house софт, вроде
 MY> hasher, gear и т.п.

А вот на остальной софт вешать такие штуки можно ТОЛЬКО в апстрим. Ибо
перемещение конифгурационных файлов - это невежливо по отношению к
пользователям. Либо же такое перемещение нужно делать полноценным, с
добавлением кода, который перекладывает старые конфиги в новое место,
предупреждает о переезде etc.

-- 

Re: [devel] ~/.config/ (was gear-tarimport)

[Eugene Ostapets]

31.01.07, Damir Shayhutdinov<damir altlinux.org> написал(а):
> > Тогда ждать появления .config в etcskel или предусматривать в программах
> > создание не только ~/.config/someprg.conf, а и самого ~/.config ?
>
> Господа, а вы уверены, что стоит заниматься этим во время фриза?
>
> P.S. не пользуюсь mc, поэтому наличие и количество dotfiles в хомяке
> меня никак не задевает. А вот миграцию с других дистрибутивов
> введением ~/.config можно запросто осложнить.
Пользователям mc проще всего, они и так себя неплохо чувствуют,
откючая/включая показ dotfiles, а вот остальным приходится ls -la |
less гонять, чтобы понять где и как хранятся конфигурационные файлы (а
это может быть и фай, и каталог, да и вообще - сразу в ~/.config, если
апстрим озадачился поддержкой f.d.o). Я не говорю что все бросают всё
и начинают править ВСЕ свои пакеты на предмет ~/.config, просто все
свои велосипеды лучше сразу туда отправлять. Ну и кого есть время и
силы может посмотреть на свои пакеты, обычно каталог/файл
пользовательской конфигурации задается в виде #define, а то и вообще в
виде ключа ./configure и его легко привести к нормальному виду

-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [devel] ~/.config/ (was gear-tarimport)

[Led]

В сообщении от 31 января 2007 11:57 Damir Shayhutdinov написал(a):
> > Тогда ждать появления .config в etcskel или предусматривать в программах
> > создание не только ~/.config/someprg.conf, а и самого ~/.config ?
>
> Господа, а вы уверены, что стоит заниматься этим во время фриза?
>
> P.S. не пользуюсь mc, поэтому наличие и количество dotfiles в хомяке
> меня никак не задевает. А вот миграцию с других дистрибутивов
> введением ~/.config можно запросто осложнить.

Можно осложнить, только если не оставить обратную совместимость. Т.е. 
создавать ~/.config/someprg.conf только при отсутсвии ~/.someprg.conf.

-- 
Led.

Re: [devel] ~/.config/ (was gear-tarimport)

[Damir Shayhutdinov]

> Пользователям mc проще всего, они и так себя неплохо чувствуют,
> откючая/включая показ dotfiles, а вот остальным приходится ls -la |
> less гонять, чтобы понять где и как хранятся конфигурационные файлы (а
> это может быть и фай, и каталог, да и вообще - сразу в ~/.config, если
> апстрим озадачился поддержкой f.d.o).
Обычно местоположение конфига обозначено в документации апстрима.
Патчить местоположение нужно только вместе с патчем документации.

> Я не говорю что все бросают всё
> и начинают править ВСЕ свои пакеты на предмет ~/.config, просто все
> свои велосипеды лучше сразу туда отправлять.  Ну и кого есть время и
> силы может посмотреть на свои пакеты, обычно каталог/файл
> пользовательской конфигурации задается в виде #define, а то и вообще в
> виде ключа ./configure и его легко привести к нормальному виду
Для того решения что предлагает Led в соседнем письме - надо делать
гораздо больше телодвижений.

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

Аргументов "за" - я вижу пока только два.
1. Легкость бэкапа.
2. Поддержка стандарта "f.d.o".

Из аргументов "против" - вижу
1. Трудности переезда
2. Несоответствие документации в интернете (в частности, результатов
гугления) практике в дистрибутиве.
3. Привычки.
4. ФРИЗ.

Re: [devel] I: gear-tarimport

[Mikhail Yakshin]

Денис Смирнов пишет:
> 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> 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

Вот, отлично, еще одна схема workflow у нас появилась :) Как бы ее 
проапгрейдить для git'а? Например, чтобы собираемый патч автоматически 
привязывался к пакету в git'е и прописывался как "PatchX: ..." и %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 потянут.

Т.е. отдельный маленький проект - организация общего интерфейса ко всем 
version control системам. По-моему - нужная и полезная вещь.

> Вообще многие такие вещи имеет смысл бить на пакеты из-за очень большого
> объема requires.

Согласен. Но некий базовый workflow-пакет с разумным объемом requires 
IMHO имеет право на существование.

> 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 отрабатывает именно
> так как ожидается.

Насколько я видел, когда смотрел последний раз - там просто меняется 
оборачивается использование rpmbuild или hsh в gear, если есть каталог .git.

Что бы мне лично хотелось видеть в утилите, которая собирает:

1. Возможность запуска без параметров для сборки того пакета, в 
директории с репозитарием которого я сейчас нахожусь. (Распространяется 
не только на саму директорию с .git, но и все ее поддиректории).

2. Возможность запуска, указав только имя пакета (пакет найдется в 
репозитарии $HOME/git/имя-пакета) - типа "rpmbb samba". При 
невозможности найти такой репозитарий должна быть выведена подсказка, 
какими способами заполучить такой репозитарий себе (скачать, создать, 
импортировать и т.п).

3. Возможность запуска, указав путь к репозитарию.

4. После успешной сборки - подсказку, что дальше можно сделать с 
собранным пакетом: поставить себе в систему, поставить в виртуальную 
систему, поставить

5. Утилиту(ы) с единым синтаксисом для сборки в rpmbuild и hasher - 
отличающуюся либо суффиксом в названии (build-rpmbuild, build-hasher), 
либо какой-то опцией (build --engine=rpmbuild, build --engine=hasher). 
Второе даже предпочительнее, т.к. можно этот самый engine по умолчанию 
задать через конфиг, кому как удобнее.

6. Сокрытие SRPMок как таковых от пользователя - они создаются и живут 
только где-то внутри. Наружу они выходят только для отправки в инкаминг 
и то, пока этот механизм не умрет.

Кто-нибудь может высказать еще какие-то соображения?

-- 
WBR, Mikhail Yakshin AKA GreyCat

Re: [devel] ~/.config/ (was gear-tarimport)

[Eugene Ostapets]

31.01.07, Damir Shayhutdinov<damir altlinux.org> написал(а):
> Без поддержки апстрима я ничего делать для своих пакетов не собираюсь,
> т.к. не хочу  в одиночку плыть против всемирного течения.

> Из аргументов "против" - вижу
> 1. Трудности переезда
Согласен
> 2. Несоответствие документации в интернете (в частности, результатов
> гугления) практике в дистрибутиве.
Я давно не встречал готовые рецепты в интернете, вне зависимости от
того, какой дистрибутив настраивал... По закону подлости рецепт всегда
шел к другому дистрибутиву, обычно Slackware (они самые пишущие,
наверное потому что из коробки у них вообще ничего не работает)
> 3. Привычки.
$XDG_CONFIG_HOME переопределяете в $HOME и привычки на месте
> 4. ФРИЗ.
Ну, если это назвать фризом...

А что вы скажете на такое предложение: все майнтейнеры пакетов,
хранящих пользовательские настройки не в соотвествии с f.d.o должны
повесить багу в апстрим по поводу места для них, а самые смелые могут
сделать это вместе с патчем, реализующим такой переезд.
-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [devel] I: gear-tarimport

[Mikhail Yakshin]

Mikhail Gusarov пишет:
> Twas brillig at 12:33:42 when Mikhail Yakshin did gyre and gimble:
> 
>  MY> В comfort исправлю путь к конфигу в ближайшее время. Может быть
>  MY> повесим аналогичные FR на хотя бы наш in-house софт, вроде
>  MY> hasher, gear и т.п.
> 
> А вот на остальной софт вешать такие штуки можно ТОЛЬКО в апстрим. Ибо
> перемещение конифгурационных файлов - это невежливо по отношению к
> пользователям. Либо же такое перемещение нужно делать полноценным, с
> добавлением кода, который перекладывает старые конфиги в новое место,
> предупреждает о переезде etc.

Само собой. Никто не говорит о каких-то революционных "вот прям щаз 
перекроим пол-Сизифа и настучим всем апстримам". У нас фриз - все такие 
вещи - после. Но все новые вещи имеет смысл делать уже сейчас правильно.

-- 
WBR, Mikhail Yakshin AKA GreyCat

Re: [devel] I: gear-tarimport

[Eugene Ostapets]

31.01.07, Mikhail Yakshin<greycat altlinux.org> написал(а):
> Mikhail Gusarov пишет:
> > А вот на остальной софт вешать такие штуки можно ТОЛЬКО в апстрим. Ибо
> > перемещение конифгурационных файлов - это невежливо по отношению к
> > пользователям. Либо же такое перемещение нужно делать полноценным, с
> > добавлением кода, который перекладывает старые конфиги в новое место,
> > предупреждает о переезде etc.
>
> Само собой. Никто не говорит о каких-то революционных "вот прям щаз
> перекроим пол-Сизифа и настучим всем апстримам". У нас фриз - все такие
> вещи - после. Но все новые вещи имеет смысл делать уже сейчас правильно.
Да, и в случае появления элегантного кода на C, для автоматического
переезда настроек в ~/.config, можно при желании часть пакетов
переделать. Нужно только завести страничку на вики и там собирать
варианты. Имея в руках патч, проще убедить любой вменяемый апстрим. А
если эти патчи развесить по багзилам Fedora и OpenSuse, то и убеждать
почти никого не прийдеться:)

-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [devel] ~/.config/ (was gear-tarimport)

[Led]

В сообщении от 31 января 2007 12:30 Eugene Ostapets написал(a):
> 31.01.07, Damir Shayhutdinov<damir altlinux.org> написал(а):
> > Без поддержки апстрима я ничего делать для своих пакетов не собираюсь,
> > т.к. не хочу  в одиночку плыть против всемирного течения.
> >
> > Из аргументов "против" - вижу
> > 1. Трудности переезда
>
> Согласен
>
> > 2. Несоответствие документации в интернете (в частности, результатов
> > гугления) практике в дистрибутиве.
>
> Я давно не встречал готовые рецепты в интернете, вне зависимости от
> того, какой дистрибутив настраивал... По закону подлости рецепт всегда
> шел к другому дистрибутиву, обычно Slackware (они самые пишущие,
> наверное потому что из коробки у них вообще ничего не работает)
>
> > 3. Привычки.
>
> $XDG_CONFIG_HOME переопределяете в $HOME и привычки на месте

А сейчас она (XDG_CONFIG_HOME) у нас разве определена? У меня почему-то нет. 
Где она должна определяться? В ~/.bashrc ? Тогда это тоже на etcskel вешать?

-- 
Led.

Re: [devel] ~/.config/ (was gear-tarimport)

[Mikhail Yakshin]

Led пишет:
>>> 3. Привычки.
>> $XDG_CONFIG_HOME переопределяете в $HOME и привычки на месте
> 
> А сейчас она (XDG_CONFIG_HOME) у нас разве определена? У меня почему-то нет. 
> Где она должна определяться? В ~/.bashrc ? Тогда это тоже на etcskel вешать?

См. внимательнее, я в том же баге упомянул. Давайте уже туда, в этот баг 
перемещаться, а?..

-- 
WBR, GreyCat

Re: [devel] ~/.config/ (was gear-tarimport)

[Eugene Ostapets]

31.01.07, Led<led altlinux.ru> написал(а):
> В сообщении от 31 января 2007 12:30 Eugene Ostapets написал(a):
> > 31.01.07, Damir Shayhutdinov<damir altlinux.org> написал(а):
> > > Без поддержки апстрима я ничего делать для своих пакетов не собираюсь,
> > > т.к. не хочу  в одиночку плыть против всемирного течения.
> > >
> > > Из аргументов "против" - вижу
> > > 1. Трудности переезда
> >
> > Согласен
> >
> > > 2. Несоответствие документации в интернете (в частности, результатов
> > > гугления) практике в дистрибутиве.
> >
> > Я давно не встречал готовые рецепты в интернете, вне зависимости от
> > того, какой дистрибутив настраивал... По закону подлости рецепт всегда
> > шел к другому дистрибутиву, обычно Slackware (они самые пишущие,
> > наверное потому что из коробки у них вообще ничего не работает)
> >
> > > 3. Привычки.
> >
> > $XDG_CONFIG_HOME переопределяете в $HOME и привычки на месте
>
> А сейчас она (XDG_CONFIG_HOME) у нас разве определена? У меня почему-то нет.
> Где она должна определяться? В ~/.bashrc ? Тогда это тоже на etcskel вешать?
Цитата:http://standards.freedesktop.org/menu-spec/menu-spec-1.0.html
If $XDG_CONFIG_HOME is not set, the default value of $HOME/.config
should be used for it.

-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [devel] ~/.config/ (was gear-tarimport)

[Led]

В сообщении от 31 января 2007 12:47 Eugene Ostapets написал(a):
> 31.01.07, Led<led altlinux.ru> написал(а):
> > В сообщении от 31 января 2007 12:30 Eugene Ostapets написал(a):
> > > 31.01.07, Damir Shayhutdinov<damir altlinux.org> написал(а):
> > > > Без поддержки апстрима я ничего делать для своих пакетов не
> > > > собираюсь, т.к. не хочу  в одиночку плыть против всемирного течения.
> > > >
> > > > Из аргументов "против" - вижу
> > > > 1. Трудности переезда
> > >
> > > Согласен
> > >
> > > > 2. Несоответствие документации в интернете (в частности, результатов
> > > > гугления) практике в дистрибутиве.
> > >
> > > Я давно не встречал готовые рецепты в интернете, вне зависимости от
> > > того, какой дистрибутив настраивал... По закону подлости рецепт всегда
> > > шел к другому дистрибутиву, обычно Slackware (они самые пишущие,
> > > наверное потому что из коробки у них вообще ничего не работает)
> > >
> > > > 3. Привычки.
> > >
> > > $XDG_CONFIG_HOME переопределяете в $HOME и привычки на месте
> >
> > А сейчас она (XDG_CONFIG_HOME) у нас разве определена? У меня почему-то
> > нет. Где она должна определяться? В ~/.bashrc ? Тогда это тоже на etcskel
> > вешать?
>
> Цитата:http://standards.freedesktop.org/menu-spec/menu-spec-1.0.html
> If $XDG_CONFIG_HOME is not set, the default value of $HOME/.config
> should be used for it.

Понял, прошу прощения за невнимательность:)

-- 
Led.

Re: [devel] ~/.config/ (was gear-tarimport)

[Денис Смирнов]

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

On Wed, Jan 31, 2007 at 11:18:40AM +0200, Led wrote:

>> А кто такие etcskel team, которые пакуют etcskel? Кстати в git, если
>> верить find-package, его нет.
L> в случае нахождения пользовательских конфигов в ~/.config/ следует ли убирать 
L> из имени файлов/каталогов этих конфигов начальную точку?

Да.

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

http://freesource.info
----------------------------------------------------------------------------
Вообще, не стесняйтесь предлагать/содействовать выпуску errata
обновлений.
		-- at in devel@

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

Re: [devel] ~/.config/ (was gear-tarimport)

[Денис Смирнов]

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

On Wed, Jan 31, 2007 at 11:48:04AM +0200, Led wrote:

>> Да, очень желательно, тогда все конфигурационные каталоги будут видны
>> в выводе просто ls, а также в mc при скрытии показа dotfiles
L> Тогда ждать появления .config в etcskel или предусматривать в программах 
L> создание не только ~/.config/someprg.conf, а и самого ~/.config ?

Не забываем о тех кто обновляется, а не инсталлирует заново. Моему ~/ уже
несколько лет, и ставить его из etcskel я более не собираюсь никогда.

Поэтому -- создавать обязательно.

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

http://freesource.info
----------------------------------------------------------------------------
<shulik> ребятки - а какой в Мастере 2.4 есть графический клиент ОСЛА?

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

Re: [devel] ~/.config/ (was gear-tarimport)

[Денис Смирнов]

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

On Wed, Jan 31, 2007 at 12:35:09PM +0300, Mikhail Yakshin wrote:

>> Да, очень желательно, тогда все конфигурационные каталоги будут видны
>> в выводе просто ls, а также в mc при скрытии показа dotfiles
MY> Ну, тогда, видимо, я сделаю ~/.config/Sisyphusrc, хорошо?

~/.config/sisyphusrc, не нужно плодить uppercase там где ненужно. В
специфических скриптах использование больших букв оправдано исключительно
для непересекаемости с дистрибутивными.

IMHO, после утверждения, даже скрипты должны быть все lower case. Иначе
набирать неудобно.

ВИмена начинающиеся с большой буквы, IMHO, допустимы только для локальных
alias'ов и скриптов.

А ещё лучше, если все-таки будешь смотреть в XDG_* переменные. Но это я
слишком многого хочу :)

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

http://freesource.info
----------------------------------------------------------------------------
Не надо abisuite выкидывать. Он нормальный и я им _пользуюсь_
		-- rider in devel@

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

Re: [devel] ~/.config/ (was gear-tarimport)

[Денис Смирнов]

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

On Wed, Jan 31, 2007 at 12:43:37PM +0200, Led wrote:

L> А сейчас она (XDG_CONFIG_HOME) у нас разве определена? У меня почему-то нет. 
L> Где она должна определяться? В ~/.bashrc ? Тогда это тоже на etcskel вешать?

Она не обязана быть определена. У неё дефолт -- .config. То бишь если
переменная есть, пользуемся ей, а если нет -- ~/.config.

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

http://freesource.info
----------------------------------------------------------------------------
<hiddenman> а ooops: 0002 в 95 году что означал, интересно?
<AMorozov> hiddenman: жопу номер 2

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

Re: [devel] ~/.config/ (was gear-tarimport)

[Led]

В сообщении от 31 января 2007 13:38 Денис Смирнов написал(a):
> On Wed, Jan 31, 2007 at 12:43:37PM +0200, Led wrote:
>
> L> А сейчас она (XDG_CONFIG_HOME) у нас разве определена? У меня почему-то
> нет. L> Где она должна определяться? В ~/.bashrc ? Тогда это тоже на
> etcskel вешать?
>
> Она не обязана быть определена. У неё дефолт -- .config. То бишь если
> переменная есть, пользуемся ей, а если нет -- ~/.config.

Да, спасибо, уже ткнули в "первоисточник":)

-- 
Led.

Re: [devel] ~/.config/ (was gear-tarimport)

[Денис Смирнов]

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

On Wed, Jan 31, 2007 at 01:21:08PM +0300, Damir Shayhutdinov wrote:

DS> Аргументов "за" - я вижу пока только два.
DS> 1. Легкость бэкапа.
DS> 2. Поддержка стандарта "f.d.o".

3. Упрощение навигации.

Вообще-то мне одной 1-й причины достаточно чтобы с этим заморачиваться.
Кроме того для тех у кого множество пользователей можно делать и ещё
интереснее. Делается отдельный раздел типа /var/etc, в котором лежат
/var/etc/<username>, и XDG_HOME_CONFIG направляется для всех пользователей
туда.

Бэкап превращается в одно удовольствие.

DS> Из аргументов "против" - вижу
DS> 1. Трудности переезда

Нету. XDG_HOME_CONFIG=~/, и проблема расстворилась в воздухе. Кроме того
разумно в качестве fallback если конфига нет в правильном месте, все-таки
искать его в $HOME.

DS> 2. Несоответствие документации в интернете (в частности, результатов
DS> гугления) практике в дистрибутиве.

Единственная проблема. И то не сказал бы что очень актуальная.

DS> 3. Привычки.

Одна строчка в bash_profile и привычки на месте.

DS> 4. ФРИЗ.

Какой такой фриз? Кто-то давно в sisyphus-cybertalk не заглядывал :)

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

http://freesource.info
----------------------------------------------------------------------------
> Какой классный номер 3333 :)
Ага, небось закрывать жалко было? :)
		-- ldv in #3333

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

Re: [devel] ~/.config/ (was gear-tarimport)

[Dmitry V. Levin]

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

On Wed, Jan 31, 2007 at 02:42:27PM +0300, Денис Смирнов wrote:
> DS> 4. ФРИЗ.
> 
> Какой такой фриз? Кто-то давно в sisyphus-cybertalk не заглядывал :)

Это у нас фриз так выглядит.  Усё под контролем. :)


-- 
ldv

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

Re: [devel] ~/.config/ (was gear-tarimport)

[Mikhail Yakshin]

Денис Смирнов пишет:
> On Wed, Jan 31, 2007 at 12:35:09PM +0300, Mikhail Yakshin wrote:
> 
>>> Да, очень желательно, тогда все конфигурационные каталоги будут видны
>>> в выводе просто ls, а также в mc при скрытии показа dotfiles
> MY> Ну, тогда, видимо, я сделаю ~/.config/Sisyphusrc, хорошо?
> 
> ~/.config/sisyphusrc, не нужно плодить uppercase там где ненужно. В
> специфических скриптах использование больших букв оправдано исключительно
> для непересекаемости с дистрибутивными.

Пусть тогда будет comfortrc, чтобы нам по этому вопросу не спорить.

> IMHO, после утверждения, даже скрипты должны быть все lower case. Иначе
> набирать неудобно.
> 
> ВИмена начинающиеся с большой буквы, IMHO, допустимы только для локальных
> alias'ов и скриптов.

Не согласен с этим утверждением. Для разделения дистрибутивный-локальный 
в мире придуманы всякие *local* и т.е. разделения по директориям. А 
upper и lower-case позволяют сильно упростить и разредить completion 
space там, где это действительно полезно.

Если смотреть на s* или даже на si* - то на первое у меня 104 
комплишена, на второе - 3 (sirtopnm, sisyphus_check, size). Все они не 
имеют прямого отношения к тому, что сейчас делают скрипты Sisyphus-* и 
если их переименовать в sisyphus-*, то количество нажатий на клавиши с 2 
(S [tab]), увеличится до 4 (s i s [tab]), причем туда еще начнет 
попадать sisyphus_check, который к ним не имеет отношения - он - 
инструмент низкого уровня.

На самом деле у нас есть не так много утилит командной строки, которые 
вызываются напрямую. Например, есть масса всяких KDE-шных k* или 
гномовских g*, которые при работе в безиксовом терминале вряд ли имеет 
смысл включать в комплишен - но, тем не менее, включают - и в итоге там 
все замусорено. На "s" народ усиленно злоупотребляет всякими show*, set* 
и start*, которые в массе своей там не запускаются и т.п.

Интересно было бы выслушать аргументированные мнения по этому вопросу, в 
идеале - подкрепленные фактами типа "вот там сделано так, потому что". 
Если кто-то знает, куда можно меня ткнуть почитать - буду рад.

> А ещё лучше, если все-таки будешь смотреть в XDG_* переменные. Но это я
> слишком многого хочу :)

Нет, не слишком. Скоро скоммичу.

-- 
WBR, Mikhail Yakshin AKA GreyCat

Re: [devel] ~/.config/ (was gear-tarimport)

[Mikhail Yakshin]

Денис Смирнов пишет:
> DS> Из аргументов "против" - вижу
> DS> 1. Трудности переезда
> 
> Нету. XDG_HOME_CONFIG=~/, и проблема расстворилась в воздухе. Кроме того
> разумно в качестве fallback если конфига нет в правильном месте, все-таки
> искать его в $HOME.

Нет, это не так - если в $XDG_HOME_CONFIG будут складываться configrc, а 
в ~/ - .configrc. Либо тогда нельзя убирать эти точки.

-- 
WBR, Mikhail Yakshin AKA GreyCat

Re: [devel] I: gear-tarimport

[Денис Смирнов]

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

On Wed, Jan 31, 2007 at 01:22:15PM +0300, Mikhail Yakshin wrote:

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

:)

Ещё бы ты принял мою мысль о том чтобы жестоко пилить пакеты вроде spt3 и
comfort на более мелкие пакеты, и мы могли бы наконец объединить наши
усилия вместо того чтобы трепаться :)

>> Сейчас я его использую в следующем случае:
>>  - rpmbb <spec>
>>  - В BUILD имеем несобравшийся пакет
>>  - переименовываю то что пытаюсь править в .orig и запускаю make (чтобы не
>>    пересобирать весь пакет)
>>  - повторяю предыдущий шаг до тех пор пока пакет не соберется
>>  - ptch > 1.patch
>>  - переношу этот патч в каталог с git, и либо привязываю его как новый
>>    патч к пакету, либо набираю patch -p0 < 1.patch
MY> Вот, отлично, еще одна схема workflow у нас появилась :) Как бы ее 
MY> проапгрейдить для git'а? Например, чтобы собираемый патч автоматически 
MY> привязывался к пакету в git'е и прописывался как "PatchX: ..." и %patch 
MY> что-то там?

Ещё пока не выработалась схема по правильной работе с патчами в git.
Вообще-то они должны быть в отдельных бранчах. Хранить патчи в виде патчей
при использовании git это очень нехорошо.

> MY>> ptch_filter - один из самых интересных, по идее, скриптов - он как-то
> MY>> хитро фильтрует патчи - но как - я с первого взгляда не понял.
>> Он глючный, поэтому и лежит в отдельном пакете :( Он мне здорово помогал
>> обрабатывать результат  сравнения бранчей астериска.
MY> Его как-то более универсально можно использовать? И - в идеале - 
MY> учитывая то, что пакет лежит в репозитарии?

Этот скрипт не пакуется в пакет. Он лежит как и все скрипты в том каталоге
так, как заготовка, на случай если я или кто ещё захочет этим
воспользоваться как базой.

>> Когда-нибудь я озверею и напишу даже скрипт Commit :)
>> Вообще эта группа недоскриптов если и нужна, то их следует упаковать в
>> отдельный пакет. Хотя бы потому что они тянут зависимость и на git, и на
>> svn. А если я чего-нибудь не того выпью, то и на cvs потянут.
MY> Т.е. отдельный маленький проект - организация общего интерфейса ко всем 
MY> version control системам. По-моему - нужная и полезная вещь.

Да.

>> Вообще многие такие вещи имеет смысл бить на пакеты из-за очень большого
>> объема requires.
MY> Согласен. Но некий базовый workflow-пакет с разумным объемом requires 
MY> IMHO имеет право на существование.

Думаю скорее группа пакетов для разных workflow. Например gear-svnupdate
не должен лежать там же где все остальное. Потому что он хочет svn,
который не всем нужен.

>> Думаю да. В любом случае получится один low level и стайка high level
>> пакетов.
>> Кстати etersoft-build-utils мы с lav@ уже давно допинали до
>> работоспособности с gear. rpmbb <specname> в git repo отрабатывает именно
>> так как ожидается.
MY> Насколько я видел, когда смотрел последний раз - там просто меняется 
MY> оборачивается использование rpmbuild или hsh в gear, если есть каталог .git.

Да.

MY> Что бы мне лично хотелось видеть в утилите, которая собирает:
MY> 1. Возможность запуска без параметров для сборки того пакета, в 
MY> директории с репозитарием которого я сейчас нахожусь. (Распространяется 
MY> не только на саму директорию с .git, но и все ее поддиректории).

Гм. Думал Виталий не будет протестовать против патча :)

MY> 2. Возможность запуска, указав только имя пакета (пакет найдется в 
MY> репозитарии $HOME/git/имя-пакета) - типа "rpmbb samba". При 
MY> невозможности найти такой репозитарий должна быть выведена подсказка, 
MY> какими способами заполучить такой репозитарий себе (скачать, создать, 
MY> импортировать и т.п).

Тогда вопрос о правильной схеме размещения. У меня, например, из-за обилия
пакетов структура такая:
git/ALTLinux -- там хранится все пакеты что я отправил на git.alt
git/ALTLinux/asterisk -- все связаное с астериском
git/ALTLinux/appliance -- appliance-*

и т. д. Я не представляю как это сделать пригодным для всех способом.

MY> 3. Возможность запуска, указав путь к репозитарию.
MY> 4. После успешной сборки - подсказку, что дальше можно сделать с 
MY> собранным пакетом: поставить себе в систему, поставить в виртуальную 
MY> систему, поставить

Это уже обертка.

MY> 5. Утилиту(ы) с единым синтаксисом для сборки в rpmbuild и hasher - 
MY> отличающуюся либо суффиксом в названии (build-rpmbuild, build-hasher), 
MY> либо какой-то опцией (build --engine=rpmbuild, build --engine=hasher). 
MY> Второе даже предпочительнее, т.к. можно этот самый engine по умолчанию 
MY> задать через конфиг, кому как удобнее.

Сейчас так и есть с etersoft-build-utils (правда первый вариант). Так как
отличия в одной букве утилиты, это вполне приемлимо. И даже удобнее чем
второй вариант.

MY> 6. Сокрытие SRPMок как таковых от пользователя - они создаются и живут 
MY> только где-то внутри. Наружу они выходят только для отправки в инкаминг 
MY> и то, пока этот механизм не умрет.

Опять же при сборке через rpmbb так и происходит.

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

http://freesource.info
----------------------------------------------------------------------------
Никогда не меняйте uid вручную, пользуйтесь usermod(8).
		-- ldv in community@

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

Re: [devel] ~/.config/ (was gear-tarimport)

[Денис Смирнов]

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

On Wed, Jan 31, 2007 at 03:26:51PM +0300, Mikhail Yakshin wrote:

>> Нету. XDG_HOME_CONFIG=~/, и проблема расстворилась в воздухе. Кроме того
>> разумно в качестве fallback если конфига нет в правильном месте, все-таки
>> искать его в $HOME.
MY> Нет, это не так - если в $XDG_HOME_CONFIG будут складываться configrc, а 
MY> в ~/ - .configrc. Либо тогда нельзя убирать эти точки.

Можно при поиске их в ~/ добавлять эти точки, это не сложно.

/me сейчас медитирует над тем, чтобы простую либу на C под это дело
написать.

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

http://freesource.info
----------------------------------------------------------------------------
АФОРИЗМ МАТЦА
 Вывод - то место в тексте, где вы устали думать.

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

Re: [devel] ~/.config/ (was gear-tarimport)

[Денис Смирнов]

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

On Wed, Jan 31, 2007 at 03:24:51PM +0300, Mikhail Yakshin wrote:

>> ~/.config/sisyphusrc, не нужно плодить uppercase там где ненужно. В
>> специфических скриптах использование больших букв оправдано исключительно
>> для непересекаемости с дистрибутивными.
MY> Пусть тогда будет comfortrc, чтобы нам по этому вопросу не спорить.

Кстати лучше даже просто comfort. То что это 'rc' ясно из того что он
лежит в ~/.config.

>> IMHO, после утверждения, даже скрипты должны быть все lower case. Иначе
>> набирать неудобно.
>> ВИмена начинающиеся с большой буквы, IMHO, допустимы только для локальных
>> alias'ов и скриптов.
MY> Не согласен с этим утверждением. Для разделения дистрибутивный-локальный 
MY> в мире придуманы всякие *local* и т.е. разделения по директориям. А 
MY> upper и lower-case позволяют сильно упростить и разредить completion 
MY> space там, где это действительно полезно.

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

MY> Если смотреть на s* или даже на si* - то на первое у меня 104 
MY> комплишена, на второе - 3 (sirtopnm, sisyphus_check, size). Все они не 
MY> имеют прямого отношения к тому, что сейчас делают скрипты Sisyphus-* и 
MY> если их переименовать в sisyphus-*, то количество нажатий на клавиши с 2 
MY> (S [tab]), увеличится до 4 (s i s [tab]), причем туда еще начнет 
MY> попадать sisyphus_check, который к ним не имеет отношения - он - 
MY> инструмент низкого уровня.

Вообще тема имен должна обсуждаться, увы, после формирования списка. Вон
rpm* использующиеся в etersoft-build-utils оказались крайне удачным
решением.

MY> На самом деле у нас есть не так много утилит командной строки, которые 
MY> вызываются напрямую. Например, есть масса всяких KDE-шных k* или 
MY> гномовских g*, которые при работе в безиксовом терминале вряд ли имеет 
MY> смысл включать в комплишен - но, тем не менее, включают - и в итоге там 
MY> все замусорено. На "s" народ усиленно злоупотребляет всякими show*, set* 
MY> и start*, которые в массе своей там не запускаются и т.п.

Кстати интересная тема для обдумывания, как бы зачистить completion space
от мусора.

MY> Интересно было бы выслушать аргументированные мнения по этому вопросу, в 
MY> идеале - подкрепленные фактами типа "вот там сделано так, потому что". 
MY> Если кто-то знает, куда можно меня ткнуть почитать - буду рад.
>> А ещё лучше, если все-таки будешь смотреть в XDG_* переменные. Но это я
>> слишком многого хочу :)
MY> Нет, не слишком. Скоро скоммичу.

Супер!

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

http://freesource.info
----------------------------------------------------------------------------
Русские программисты всегда в настроении для программирования.

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

Re: [devel] ~/.config/ (was gear-tarimport)

[Damir Shayhutdinov]

> MY> Нет, это не так - если в $XDG_HOME_CONFIG будут складываться configrc, а
> MY> в ~/ - .configrc. Либо тогда нельзя убирать эти точки.
>
> Можно при поиске их в ~/ добавлять эти точки, это не сложно.

А как же тогда тезис о том, что достаточно будет всего лишь
переопределить XDG_HOME_CONFIG в HOME и все будет как было? Если есть
разница в обработке конфигов из $XFG_HOME_CONFIG и $HOME, то одно
просто так на другое не заменишь.

Re: [devel] ~/.config/ (was gear-tarimport)

[Led]

В сообщении от 31 января 2007 14:43 Денис Смирнов написал(a):
> On Wed, Jan 31, 2007 at 03:26:51PM +0300, Mikhail Yakshin wrote:
> >> Нету. XDG_HOME_CONFIG=~/, и проблема расстворилась в воздухе. Кроме того
> >> разумно в качестве fallback если конфига нет в правильном месте,
> >> все-таки искать его в $HOME.
>
> MY> Нет, это не так - если в $XDG_HOME_CONFIG будут складываться configrc,
> а MY> в ~/ - .configrc. Либо тогда нельзя убирать эти точки.
>
> Можно при поиске их в ~/ добавлять эти точки, это не сложно.
>
> /me сейчас медитирует над тем, чтобы простую либу на C под это дело
> написать.

Скорее всего, подобной либой можно будет пользоваться только в простейших 
случаях: когда имеются только ~/.prgrc файлы. в случае ~/.prg каталогов это 
уже врядли... особенно если в этой ~/.prg лежат файлы кандитаты в 
~/.local/share и ~/.cache

-- 
Led.

Re: [devel] ~/.config/ (was gear-tarimport)

[Mikhail Yakshin]

Денис Смирнов пишет:
>>> ~/.config/sisyphusrc, не нужно плодить uppercase там где ненужно. В
>>> специфических скриптах использование больших букв оправдано исключительно
>>> для непересекаемости с дистрибутивными.
> MY> Пусть тогда будет comfortrc, чтобы нам по этому вопросу не спорить.
> 
> Кстати лучше даже просто comfort. То что это 'rc' ясно из того что он
> лежит в ~/.config.

Так и сделал.

>>> IMHO, после утверждения, даже скрипты должны быть все lower case. Иначе
>>> набирать неудобно.
>>> ВИмена начинающиеся с большой буквы, IMHO, допустимы только для локальных
>>> alias'ов и скриптов.
> MY> Не согласен с этим утверждением. Для разделения дистрибутивный-локальный 
> MY> в мире придуманы всякие *local* и т.е. разделения по директориям. А 
> MY> upper и lower-case позволяют сильно упростить и разредить completion 
> MY> space там, где это действительно полезно.
> 
> Как эти local мне помогут? Я написал утилитку и хочу быть увереным, что в
> сизифе никогда не появится утилиты с тем же именем, как мне поступить?

А зачем быть в этом уверенным? Порядок вызова утилит задается в PATH. 
local и alias'ы по жизни там первичны.

> MY> Если смотреть на s* или даже на si* - то на первое у меня 104 
> MY> комплишена, на второе - 3 (sirtopnm, sisyphus_check, size). Все они не 
> MY> имеют прямого отношения к тому, что сейчас делают скрипты Sisyphus-* и 
> MY> если их переименовать в sisyphus-*, то количество нажатий на клавиши с 2 
> MY> (S [tab]), увеличится до 4 (s i s [tab]), причем туда еще начнет 
> MY> попадать sisyphus_check, который к ним не имеет отношения - он - 
> MY> инструмент низкого уровня.
> 
> Вообще тема имен должна обсуждаться, увы, после формирования списка. Вон
> rpm* использующиеся в etersoft-build-utils оказались крайне удачным
> решением.

Не знаю, лично мне они не кажутся очень удачным решением. По крайней 
мере ответственно могу заявить, что для человека, который начинает 
осваивать etersoft-build-utils и ему вываливается по rpm* аж 12 утилит с 
загадочными названиями из 1-2-3 букв (не считая еще собственно, rpm, 
rpmbuild, rpmi, rpmu, rpmquery) - наступает неприятная растерянность и 
чувство, что абсолютно ничего не понимаешь. Проверялось как минимум на 
себе и еще 2 людях. Понятно, что тут все сделано для максимальной 
краткости, но подход с комплишенами мне кажется более дружественным (его 
же сейчас и используют и hasher, и gear, и git, и многие другие).

> MY> На самом деле у нас есть не так много утилит командной строки, которые 
> MY> вызываются напрямую. Например, есть масса всяких KDE-шных k* или 
> MY> гномовских g*, которые при работе в безиксовом терминале вряд ли имеет 
> MY> смысл включать в комплишен - но, тем не менее, включают - и в итоге там 
> MY> все замусорено. На "s" народ усиленно злоупотребляет всякими show*, set* 
> MY> и start*, которые в массе своей там не запускаются и т.п.
> 
> Кстати интересная тема для обдумывания, как бы зачистить completion space
> от мусора.

Вынесем ее, пожалуй, отдельно. Есть некие отвлеченные мысли по 
прикручиванию минимального интеллекта к нему, чтобы он угадывал, что 
предлагать человеку, что ему нужно прямо сейчас.

> MY> Интересно было бы выслушать аргументированные мнения по этому вопросу, в 
> MY> идеале - подкрепленные фактами типа "вот там сделано так, потому что". 
> MY> Если кто-то знает, куда можно меня ткнуть почитать - буду рад.
>>> А ещё лучше, если все-таки будешь смотреть в XDG_* переменные. Но это я
>>> слишком многого хочу :)
> MY> Нет, не слишком. Скоро скоммичу.
> 
> Супер!

http://git.altlinux.org/people/greycat/packages/?p=comfort.git;a=commit;h=e98265933e2166ce4d79224d7d25066cf2a170b0

-- 
WBR, GreyCat

Re: [devel] ~/.config/ (was gear-tarimport)

[Sergey Vlasov]

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

On Wed, Jan 31, 2007 at 03:46:03PM +0300, Денис Смирнов wrote:
> On Wed, Jan 31, 2007 at 03:24:51PM +0300, Mikhail Yakshin wrote:
> 
> >> ~/.config/sisyphusrc, не нужно плодить uppercase там где ненужно. В
> >> специфических скриптах использование больших букв оправдано исключительно
> >> для непересекаемости с дистрибутивными.
> MY> Пусть тогда будет comfortrc, чтобы нам по этому вопросу не спорить.
> 
> Кстати лучше даже просто comfort. То что это 'rc' ясно из того что он
> лежит в ~/.config.

Одного файла хватит?
Может быть, сразу создать каталог ~/.config/comfort/ ?

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

Re: [devel] ~/.config/ (was gear-tarimport)

[Денис Смирнов]

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

On Wed, Jan 31, 2007 at 02:59:31PM +0200, Led wrote:

L> Скорее всего, подобной либой можно будет пользоваться только в простейших 
L> случаях: когда имеются только ~/.prgrc файлы. в случае ~/.prg каталогов это 
L> уже врядли... особенно если в этой ~/.prg лежат файлы кандитаты в 
L> ~/.local/share и ~/.cache

Можно-можно :) Про share/cache пока забываем на первое время. Эта работка
посложнее будет.

Только логика использования чуть меняется.

Либа ищет _путь_ конфига. Находит. Только можно в качестве конфига её
просить не путь к файлу, а путь к _каталогу_. Тогда отрабатывает все
нормально.

Концепт ушел в git под именем libxdgconfig.

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

http://freesource.info
----------------------------------------------------------------------------
> $ grep mkdir /usr/lib/rpm/macros
Лучше rpm --showrc|grep, т.к. макросы еще и в /etc/rpm лежат.
		-- wrar in sisyphus@

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

Re: [devel] ~/.config/ (was gear-tarimport)

[Денис Смирнов]

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

On Wed, Jan 31, 2007 at 03:54:20PM +0300, Damir Shayhutdinov wrote:

> MY>> Нет, это не так - если в $XDG_HOME_CONFIG будут складываться configrc, а
> MY>> в ~/ - .configrc. Либо тогда нельзя убирать эти точки.
>> Можно при поиске их в ~/ добавлять эти точки, это не сложно.
DS> А как же тогда тезис о том, что достаточно будет всего лишь
DS> переопределить XDG_HOME_CONFIG в HOME и все будет как было? Если есть
DS> разница в обработке конфигов из $XFG_HOME_CONFIG и $HOME, то одно
DS> просто так на другое не заменишь.

Глянь на libxdgconfig в моем git. Я это обошел.

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

http://freesource.info
----------------------------------------------------------------------------
<drF_ckoff> The official Gentoo motto is, "If it moves, compile it."
<raorn> drF_ckoff: а если не moves, растолкай и compile

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

Re: [devel] ~/.config/ (was gear-tarimport)

[Денис Смирнов]

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

On Wed, Jan 31, 2007 at 04:01:02PM +0300, Mikhail Yakshin wrote:

>> Как эти local мне помогут? Я написал утилитку и хочу быть увереным, что в
>> сизифе никогда не появится утилиты с тем же именем, как мне поступить?
MY> А зачем быть в этом уверенным? Порядок вызова утилит задается в PATH. 
MY> local и alias'ы по жизни там первичны.

Это неудобно. namespaces лучше все-таки разделять.
И утилиты в дистрибутиве начинающиеся с большой буквы это плохо.

> MY>> Если смотреть на s* или даже на si* - то на первое у меня 104 
> MY>> комплишена, на второе - 3 (sirtopnm, sisyphus_check, size). Все они не 
> MY>> имеют прямого отношения к тому, что сейчас делают скрипты Sisyphus-* и 
> MY>> если их переименовать в sisyphus-*, то количество нажатий на клавиши с 2 
> MY>> (S [tab]), увеличится до 4 (s i s [tab]), причем туда еще начнет 
> MY>> попадать sisyphus_check, который к ним не имеет отношения - он - 
> MY>> инструмент низкого уровня.
>> Вообще тема имен должна обсуждаться, увы, после формирования списка. Вон
>> rpm* использующиеся в etersoft-build-utils оказались крайне удачным
>> решением.
MY> Не знаю, лично мне они не кажутся очень удачным решением. По крайней 
MY> мере ответственно могу заявить, что для человека, который начинает 
MY> осваивать etersoft-build-utils и ему вываливается по rpm* аж 12 утилит с 
MY> загадочными названиями из 1-2-3 букв (не считая еще собственно, rpm, 
MY> rpmbuild, rpmi, rpmu, rpmquery) - наступает неприятная растерянность и 
MY> чувство, что абсолютно ничего не понимаешь. Проверялось как минимум на 
MY> себе и еще 2 людях. Понятно, что тут все сделано для максимальной 
MY> краткости, но подход с комплишенами мне кажется более дружественным (его 
MY> же сейчас и используют и hasher, и gear, и git, и многие другие).

rpmbb набрать быстрее чем любой вариант completion.

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

http://freesource.info
----------------------------------------------------------------------------
Исправлено за три часа _до_ появления этой баги ;)
		-- rider in #9066

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

Re: [devel] ~/.config/ (was gear-tarimport)

[Damir Shayhutdinov]

> DS> А как же тогда тезис о том, что достаточно будет всего лишь
> DS> переопределить XDG_HOME_CONFIG в HOME и все будет как было? Если есть
> DS> разница в обработке конфигов из $XFG_HOME_CONFIG и $HOME, то одно
> DS> просто так на другое не заменишь.
>
> Глянь на libxdgconfig в моем git. Я это обошел.
Поглядел.

Что-то API получился не thread-friendly (static char rc)

И получается что если у меня XFG_HOME_CONFIG=$HOME, то все мои
.dotfiles будут переименованы в dotfiles и будут видны везде?
Непорядок!

/* If file exists in wrong place -- try to move in! */
43         if( access(homefn, F_OK) )
44                 rename(homefn, rightfn);
Если есть файл ~/.foo - то переименовать его в ~/foo

Ай-яй-яй!

Re: [devel] ~/.config/ (was gear-tarimport)

[Damir Shayhutdinov]

> /* If file exists in wrong place -- try to move in! */
> 43         if( access(homefn, F_OK) )
> 44                 rename(homefn, rightfn);
> Если есть файл ~/.foo - то переименовать его в ~/foo

Не говоря уж о том, что access возвращает 0 в случае успеха.

Re: [devel] ~/.config/ (was gear-tarimport)

[Mikhail Yakshin]

Денис Смирнов пишет:
> Либа ищет _путь_ конфига. Находит. Только можно в качестве конфига её
> просить не путь к файлу, а путь к _каталогу_. Тогда отрабатывает все
> нормально.
> 
> Концепт ушел в git под именем libxdgconfig.

Если смотреть в эти стандарты, то есть еще:

There is a single base directory relative to which user-specific 
configuration files should be written. This directory is defined by the 
environment variable $XDG_CONFIG_HOME.

There is a set of preference ordered base directories relative to which 
configuration files should be searched. This set of directories is 
defined by the environment variable $XDG_CONFIG_DIRS.

$XDG_CONFIG_DIRS defines the preference-ordered set of base directories 
to search for configuration files in addition to the $XDG_CONFIG_HOME 
base directory. The directories in $XDG_CONFIG_DIRS should be seperated 
with a colon ':'.

If $XDG_CONFIG_DIRS is either not set or empty, a value equal to 
/etc/xdg should be used.

The order of base directories denotes their importance; the first 
directory listed is the most important. When the same information is 
defined in multiple places the information defined relative to the more 
important base directory takes precedent. The base directory defined by 
$XDG_DATA_HOME is considered more important than any of the base 
directories defined by $XDG_DATA_DIRS. The base directory defined by 
$XDG_CONFIG_HOME is considered more important than any of the base 
directories defined by $XDG_CONFIG_DIRS.

Т.е. надо еще проходить по списку XDG_CONFIG_DIRS и анализировать его. 
XDG_CONFIG_HOME - это только первый его элемент. И искать, видимо, нужно 
будет все-таки конкретный файл, а не только путь...

P.S. А зачем в новой библиотеке autotools использовать?

-- 
WBR, Mikhail Yakshin

Re: [devel] ~/.config/ (was gear-tarimport)

[Денис Смирнов]

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

On Wed, Jan 31, 2007 at 05:28:21PM +0300, Mikhail Yakshin wrote:

MY> The order of base directories denotes their importance; the first 
MY> directory listed is the most important. When the same information is 
MY> defined in multiple places the information defined relative to the more 
MY> important base directory takes precedent. The base directory defined by 
MY> $XDG_DATA_HOME is considered more important than any of the base 
MY> directories defined by $XDG_DATA_DIRS. The base directory defined by 
MY> $XDG_CONFIG_HOME is considered more important than any of the base 
MY> directories defined by $XDG_CONFIG_DIRS.
MY> Т.е. надо еще проходить по списку XDG_CONFIG_DIRS и анализировать его. 

Понял, сделаю.

MY> XDG_CONFIG_HOME - это только первый его элемент. И искать, видимо, нужно 
MY> будет все-таки конкретный файл, а не только путь...

Я думаю это сделать отдельной функцией. Текущий вариант удобен тем, что
сможет таки _перенести_ конфиг или каталог с конфигами.

MY> P.S. А зачем в новой библиотеке autotools использовать?

Какие варианты?

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

http://freesource.info
----------------------------------------------------------------------------
Если были бы известны правила для NMU, я бы сделал NMU.
		-- at in devel@

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

Re: [devel] ~/.config/ (was gear-tarimport)

[Денис Смирнов]

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

On Wed, Jan 31, 2007 at 05:22:36PM +0300, Damir Shayhutdinov wrote:

DS> Что-то API получился не thread-friendly (static char rc)

Я об этом долго думал. И не знаю как делать правильнее.
Я могу класть переменную в TLS, а могу просто malloc и возвращать
результат.

Во втором случае ей сложнее будет пользоваться (лишний free будут
хронически забывать).

DS> И получается что если у меня XFG_HOME_CONFIG=$HOME, то все мои
DS> .dotfiles будут переименованы в dotfiles и будут видны везде?
DS> Непорядок!

Принято! В случае XFG_HOME_CONFIG=$HOME действительно никакой логики
включаться не должно.

Как мне проверить это равенство?

Ещё вопрос, XFG_HOME_CONFIG может быть и "~/.blablabla". Тильду чем
правильно раскрывать?

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

http://freesource.info
----------------------------------------------------------------------------
LATER наступило.  Патчи в аттачах.
		-- raorn in #5429

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

Re: [devel] ~/.config/ (was gear-tarimport)

[Денис Смирнов]

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

On Wed, Jan 31, 2007 at 05:24:48PM +0300, Damir Shayhutdinov wrote:

>> /* If file exists in wrong place -- try to move in! */
>> 43         if( access(homefn, F_OK) )
>> 44                 rename(homefn, rightfn);
>> Если есть файл ~/.foo - то переименовать его в ~/foo
DS> Не говоря уж о том, что access возвращает 0 в случае успеха.

fixed.

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

http://freesource.info
----------------------------------------------------------------------------
Пока нет решения суда, никто ни в чём не виноват.
		-- lav in sisyphus@

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

Re: [devel] ~/.config/ (was gear-tarimport)

[Damir Shayhutdinov]

> DS> Что-то API получился не thread-friendly (static char rc)
>
> Я об этом долго думал. И не знаю как делать правильнее.
> Я могу класть переменную в TLS, а могу просто malloc и возвращать
> результат.
>
> Во втором случае ей сложнее будет пользоваться (лишний free будут
> хронически забывать).
Почему бы не передавать буфер куда надо покласть результат в саму
функцию (вместе с размером этого буфера конечно) в качестве
параметров?

> DS> И получается что если у меня XFG_HOME_CONFIG=$HOME, то все мои
> DS> .dotfiles будут переименованы в dotfiles и будут видны везде?
> DS> Непорядок!
>
> Принято! В случае XFG_HOME_CONFIG=$HOME действительно никакой логики
> включаться не должно.
>
> Как мне проверить это равенство?

char* xfg_home = getenv("XFG_HOME_CONFIG");
char* home = getenv("HOME");
if (xfg_home && home && strcmp(home, xfg_home) == 0)
{
 /* match */
}


> Ещё вопрос, XFG_HOME_CONFIG может быть и "~/.blablabla". Тильду чем
> правильно раскрывать?
Вообще принято использовать $HOME в качестве замены тильде.

ИМХО не надо ее раскрывать.

Пусть пользователи пишут
export XFG_HOME_CONFIG="$HOME/.mymegaconfigdir"

Re: [devel] ~/.config/ (was gear-tarimport)

[Денис Смирнов]

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

On Wed, Jan 31, 2007 at 06:27:47PM +0300, Damir Shayhutdinov wrote:

>> Я об этом долго думал. И не знаю как делать правильнее.
>> Я могу класть переменную в TLS, а могу просто malloc и возвращать
>> результат.
>> Во втором случае ей сложнее будет пользоваться (лишний free будут
>> хронически забывать).
DS> Почему бы не передавать буфер куда надо покласть результат в саму
DS> функцию (вместе с размером этого буфера конечно) в качестве
DS> параметров?

Наверное так действительно правильнее.

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

> DS>> И получается что если у меня XFG_HOME_CONFIG=$HOME, то все мои
> DS>> .dotfiles будут переименованы в dotfiles и будут видны везде?
> DS>> Непорядок!
>> Принято! В случае XFG_HOME_CONFIG=$HOME действительно никакой логики
>> включаться не должно.
>> Как мне проверить это равенство?
DS> char* xfg_home = getenv("XFG_HOME_CONFIG");
DS> char* home = getenv("HOME");
DS> if (xfg_home && home && strcmp(home, xfg_home) == 0)
DS> {
DS>  /* match */
DS> }

Вопрос -- если мы _не нашли_ файл, то есть его будут создавать. Что делать
в случае XFG_HOME_CONFIG==HOME, возврашать имя с точкой, или без?
Мне кажется что без, так что fixed. См. git.

>> Ещё вопрос, XFG_HOME_CONFIG может быть и "~/.blablabla". Тильду чем
>> правильно раскрывать?
DS> Вообще принято использовать $HOME в качестве замены тильде.
DS> ИМХО не надо ее раскрывать.
DS> Пусть пользователи пишут
DS> export XFG_HOME_CONFIG="$HOME/.mymegaconfigdir"

Понял.

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

http://freesource.info
----------------------------------------------------------------------------
Рискую получить черный шар от ldv, но не удержусь.
		-- aen in devel@



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

Re: [devel] ~/.config/ (was gear-tarimport)

[Денис Смирнов]

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

On Wed, Jan 31, 2007 at 05:28:21PM +0300, Mikhail Yakshin wrote:

MY> Т.е. надо еще проходить по списку XDG_CONFIG_DIRS и анализировать его. 
MY> XDG_CONFIG_HOME - это только первый его элемент. И искать, видимо, нужно 
MY> будет все-таки конкретный файл, а не только путь...

В общем так. XDG_CONFIG_DIRS либо patches is welcome, либо будут сильно
позже. Ибо фича нужна куда как реже.

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

http://freesource.info
----------------------------------------------------------------------------
АКСИОМА КАННА
 Если ничто другое не помогает - прочтите, наконец, инструкцию.

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

Re: [devel] ~/.config/ (was gear-tarimport)

[Damir Shayhutdinov]

> В таком случае я реализую оба варианта. То есть если передали NULL, то
> тогда пишем в статику.
Либе не помешал бы хороший manpage :)


> Вопрос -- если мы _не нашли_ файл, то есть его будут создавать. Что делать
> в случае XFG_HOME_CONFIG==HOME, возврашать имя с точкой, или без?
> Мне кажется что без, так что fixed. См. git.
Я считаю что с точкой, потому что если XFG_HOME_CONFIG==HOME, то
пользователь понимает, что будет нахламление конфигов в хомяке, и
рассчитывает что они все-таки будут начинаться с точки.
К тому же это больше соответствует тому, что было "до XFG_HOME_CONFIG".

Так что предлагаю делать с точкой, иначе будет бардак файлов в хомяке,
а его никто не хочет.

Re: [devel] ~/.config/ (was gear-tarimport)

[Денис Смирнов]

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

On Wed, Jan 31, 2007 at 07:37:47PM +0300, Damir Shayhutdinov wrote:

>> В таком случае я реализую оба варианта. То есть если передали NULL, то
>> тогда пишем в статику.
DS> Либе не помешал бы хороший manpage :)

А ты запусти doxygen :-P

А manpage... Гм. Наверное можно и написать.

>> Вопрос -- если мы _не нашли_ файл, то есть его будут создавать. Что делать
>> в случае XFG_HOME_CONFIG==HOME, возврашать имя с точкой, или без?
>> Мне кажется что без, так что fixed. См. git.
DS> Я считаю что с точкой, потому что если XFG_HOME_CONFIG==HOME, то
DS> пользователь понимает, что будет нахламление конфигов в хомяке, и
DS> рассчитывает что они все-таки будут начинаться с точки.
DS> К тому же это больше соответствует тому, что было "до XFG_HOME_CONFIG".

В смысле "мне кажется что с точкой", думал одно, написал другое. В общем
уже fixed. 

DS> Так что предлагаю делать с точкой, иначе будет бардак файлов в хомяке,
DS> а его никто не хочет.

Верю.

Thread-safe API тоже сделал.

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

http://freesource.info
----------------------------------------------------------------------------
У меня нет желания тренироваться на кошках.
		-- ldv in devel@

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

Re: [devel] ~/.config/ (was gear-tarimport)

[Damir Shayhutdinov]

> >> Принято! В случае XFG_HOME_CONFIG=$HOME действительно никакой логики
> >> включаться не должно.
> >> Как мне проверить это равенство?
> DS> char* xfg_home = getenv("XFG_HOME_CONFIG");
> DS> char* home = getenv("HOME");
> DS> if (xfg_home && home && strcmp(home, xfg_home) == 0)
> DS> {
> DS>  /* match */
> DS> }

http://git.altlinux.org/people/mithraen/packages/?p=libxdgconfig.git;a=commitdiff;h=0624b8d96ebc83b1074231c6f342b38ac692f665
Ugly Hack таки действительно "ugly"

if( !access(homefn, F_OK) && !strcmp(tmp, home))

strcmp возвращает 0, когда строки совпадают. Тут по смыслу вместо
!strcmp() надо просто strcmp().

Re: [devel] ~/.config/ (was gear-tarimport)

[Денис Смирнов]

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

On Wed, Jan 31, 2007 at 07:48:58PM +0300, Damir Shayhutdinov wrote:
> >>> Принято! В случае XFG_HOME_CONFIG=$HOME действительно никакой логики
> >>> включаться не должно.
> >>> Как мне проверить это равенство?
> DS>> char* xfg_home = getenv("XFG_HOME_CONFIG");
> DS>> char* home = getenv("HOME");
> DS>> if (xfg_home && home && strcmp(home, xfg_home) == 0)
> DS>> {
> DS>>  /* match */
> DS>> }
 DS> http://git.altlinux.org/people/mithraen/packages/?p=libxdgconfig.git;a=commitdiff;h=0624b8d96ebc83b1074231c6f342b38ac692f665
 DS> Ugly Hack таки действительно "ugly"
 DS> if( !access(homefn, F_OK) && !strcmp(tmp, home))
 DS> strcmp возвращает 0, когда строки совпадают. Тут по смыслу вместо
 DS> !strcmp() надо просто strcmp().

Про это забудь, там дальше правильный вариант должен быть.

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

http://freesource.info
----------------------------------------------------------------------------
А не то что correctly - не correctly.
		-- wrar in sisyphus@

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

Re: [devel] ~/.config/ (was gear-tarimport)

[Alexey I. Froloff]

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

* Mikhail Yakshin <greycat@> [070131 15:33]:
> (S [tab]), увеличится до 4 (s i s [tab]), причем туда еще начнет 
> попадать sisyphus_check, который к ним не имеет отношения - он - 
> инструмент низкого уровня.
И другие sisyphus_* из пакета sisuphus.

-- 
Regards,
Sir Raorn.

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

Re: [devel] Maintainer's toolbox (was: I: gear-tarimport)

[Mikhail Yakshin]

Денис Смирнов wrote:
> On Wed, Jan 31, 2007 at 01:22:15PM +0300, Mikhail Yakshin wrote:
> 
>>> Я только за. Потому как по моему личному мнению наличие в сизифе каждого
>>> пакета с именем "<firmname>..." это неявная бага. Если пакет seiros-.*
>>> используется только у меня, то ему не место в сизифе. А если используется
>>> не только мной, то почему бы не объединить все подобные утилиты в один
>>> пакет?
> MY> Ура =) Очень близкая мысль :)
> 
> :)
> 
> Ещё бы ты принял мою мысль о том чтобы жестоко пилить пакеты вроде spt3 и
> comfort на более мелкие пакеты, и мы могли бы наконец объединить наши
> усилия вместо того чтобы трепаться :)

spt3 распилен, пожалуйста, смотри. Как пилить comfort - я пока не очень
понимаю, предлагай.

>>> Сейчас я его использую в следующем случае:
>>>  - rpmbb <spec>
>>>  - В BUILD имеем несобравшийся пакет
>>>  - переименовываю то что пытаюсь править в .orig и запускаю make (чтобы не
>>>    пересобирать весь пакет)
>>>  - повторяю предыдущий шаг до тех пор пока пакет не соберется
>>>  - ptch > 1.patch
>>>  - переношу этот патч в каталог с git, и либо привязываю его как новый
>>>    патч к пакету, либо набираю patch -p0 < 1.patch
> MY> Вот, отлично, еще одна схема workflow у нас появилась :) Как бы ее 
> MY> проапгрейдить для git'а? Например, чтобы собираемый патч автоматически 
> MY> привязывался к пакету в git'е и прописывался как "PatchX: ..." и %patch 
> MY> что-то там?
> 
> Ещё пока не выработалась схема по правильной работе с патчами в git.
> Вообще-то они должны быть в отдельных бранчах. Хранить патчи в виде патчей
> при использовании git это очень нехорошо.

Значит, нам нужен как минимум обратный инструмент - который после
srpmimport конвертит "Patch: ..." + "%patch-что-то-там", заводя их в git.

>>> Вообще многие такие вещи имеет смысл бить на пакеты из-за очень большого
>>> объема requires.
> MY> Согласен. Но некий базовый workflow-пакет с разумным объемом requires 
> MY> IMHO имеет право на существование.
> 
> Думаю скорее группа пакетов для разных workflow. Например gear-svnupdate
> не должен лежать там же где все остальное. Потому что он хочет svn,
> который не всем нужен.

Нам хотя бы один базовый пока набросать %)

> MY> Что бы мне лично хотелось видеть в утилите, которая собирает:
> MY> 1. Возможность запуска без параметров для сборки того пакета, в 
> MY> директории с репозитарием которого я сейчас нахожусь. (Распространяется 
> MY> не только на саму директорию с .git, но и все ее поддиректории).
> 
> Гм. Думал Виталий не будет протестовать против патча :)
> 
> MY> 2. Возможность запуска, указав только имя пакета (пакет найдется в 
> MY> репозитарии $HOME/git/имя-пакета) - типа "rpmbb samba". При 
> MY> невозможности найти такой репозитарий должна быть выведена подсказка, 
> MY> какими способами заполучить такой репозитарий себе (скачать, создать, 
> MY> импортировать и т.п).
> 
> Тогда вопрос о правильной схеме размещения. У меня, например, из-за обилия
> пакетов структура такая:
> git/ALTLinux -- там хранится все пакеты что я отправил на git.alt
> git/ALTLinux/asterisk -- все связаное с астериском
> git/ALTLinux/appliance -- appliance-*
> и т. д. Я не представляю как это сделать пригодным для всех способом.

Ok, понял, в ближайшее время сделаю такую возможность неплоского
размещения пакетов.

determine_package() переделаю так, чтобы он, если указан полный путь
(типа "ALTLinux/asterisk/some-package") - собирал бы его, если нет - то
искал бы соответствующую директорию find'ом; если найдена одна - то
собирал бы оттуда; если их несколько - то ругался бы на то, что не может
однозначно определить, что собирать (как rpm -e, когда под критерий
подпадает >1 пакета).

> MY> 5. Утилиту(ы) с единым синтаксисом для сборки в rpmbuild и hasher - 
> MY> отличающуюся либо суффиксом в названии (build-rpmbuild, build-hasher), 
> MY> либо какой-то опцией (build --engine=rpmbuild, build --engine=hasher). 
> MY> Второе даже предпочительнее, т.к. можно этот самый engine по умолчанию 
> MY> задать через конфиг, кому как удобнее.
> 
> Сейчас так и есть с etersoft-build-utils (правда первый вариант). Так как
> отличия в одной букве утилиты, это вполне приемлимо. И даже удобнее чем
> второй вариант.

Я понял целую одну вещь: есть 2 подхода к именованию утилит:

1. Именовать в жестком unix-style - имена из 2-3, максимум 4 букв, все
аббревиативно, подобрано специально для запоминания. Типичные
представители - программы из coreutils, например.

Плюсы - быстро набирать, при 2-3-4 keystrokes спложно конкурировать с
ними по скорости набора.
Минусы - надо запоминать их все; при наличии множественных вариантов,
незначительно отличающихся друг от друга, получаем сложновоспринимаемые
наборы символов; надо продумывать названия так, чтобы они как можно
лучше ассоциировались с какими-то действиями.

2. Именовать, надеясь на комплишен. Имена тогда значительно длиннее и
максимально описательны. Возникает проблема completion space. Фактически
обязательно использование completion. Как правило, вводится некий
префикс наименования семейства утилит (git-*, gear-*, hsh-*, Sisyphus-*).

В качестве чуть альтернативной реализации - это когда делается одна
"объединяющая" утилита (как в cvs, svn, git, gem) у которой первый
параметр - команда, которую надо выполнить. Удобно, если есть умный
комплишен а ля zsh или bash-completions, довольно неудобно, если нет.

Плюсы - наглядно, не надо запоминать практически ничего, кроме первых
букв префикса.
Минусы - чуть медленнее набирать, большая надежда на completion, надо
продумывать так, чтобы удобно было комплитить и в completion попадали
только нужные команды.

Есть поклонники как одного стиля, так и другого. Поэтому, чтобы не
мешать друг другу и не ломать копий - все равно это абсолютно вопрос
привычки/удобства для конкретного человека - предлагаю сделать и так, и
так - ровно как с опциями (-f и --force). Сделать симлинками или
алиасами 2 варианта вызова - и длинный, и короткий.

-- 
WBR, Mikhail Yakshin AKA GreyCat
ALT Linux [http://www.altlinux.ru] [xmpp:greycat@altlinux.org]

Re: [devel] Maintainer's toolbox (was: I: gear-tarimport)

[Денис Смирнов]

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

On Fri, Feb 02, 2007 at 01:37:26AM +0300, Mikhail Yakshin wrote:

>> Ещё бы ты принял мою мысль о том чтобы жестоко пилить пакеты вроде spt3 и
>> comfort на более мелкие пакеты, и мы могли бы наконец объединить наши
>> усилия вместо того чтобы трепаться :)
MY> spt3 распилен, пожалуйста, смотри. Как пилить comfort - я пока не очень
MY> понимаю, предлагай.

Ok, посмотрю.

>> Ещё пока не выработалась схема по правильной работе с патчами в git.
>> Вообще-то они должны быть в отдельных бранчах. Хранить патчи в виде патчей
>> при использовании git это очень нехорошо.
MY> Значит, нам нужен как минимум обратный инструмент - который после
MY> srpmimport конвертит "Patch: ..." + "%patch-что-то-там", заводя их в git.

См. первую строчку моей цитаты. Выработается -- можно будет писать.

>> Думаю скорее группа пакетов для разных workflow. Например gear-svnupdate
>> не должен лежать там же где все остальное. Потому что он хочет svn,
>> который не всем нужен.
MY> Нам хотя бы один базовый пока набросать %)

Базовый не требует ни одной утилиты из отсутствующих в пакете gear, все
остальное -- вариации на тему :)

>> Тогда вопрос о правильной схеме размещения. У меня, например, из-за обилия
>> пакетов структура такая:
>> git/ALTLinux -- там хранится все пакеты что я отправил на git.alt
>> git/ALTLinux/asterisk -- все связаное с астериском
>> git/ALTLinux/appliance -- appliance-*
>> и т. д. Я не представляю как это сделать пригодным для всех способом.
MY> Ok, понял, в ближайшее время сделаю такую возможность неплоского
MY> размещения пакетов.
MY> determine_package() переделаю так, чтобы он, если указан полный путь
MY> (типа "ALTLinux/asterisk/some-package") - собирал бы его, если нет - то
MY> искал бы соответствующую директорию find'ом; если найдена одна - то
MY> собирал бы оттуда; если их несколько - то ругался бы на то, что не может
MY> однозначно определить, что собирать (как rpm -e, когда под критерий
MY> подпадает >1 пакета).

Разумно. Только с find'ом боюсь весело будет. Потому как в подкаталоги
репозиториев смотреть не надо.

MY> 2. Именовать, надеясь на комплишен. Имена тогда значительно длиннее и
MY> максимально описательны. Возникает проблема completion space. Фактически
MY> обязательно использование completion. Как правило, вводится некий
MY> префикс наименования семейства утилит (git-*, gear-*, hsh-*, Sisyphus-*).

А вот фиг там. git-* вообще-то deprecated, надо пользоваться git *, к
примеру. Вот как раз для удобного разделения completion namespace.

MY> В качестве чуть альтернативной реализации - это когда делается одна
MY> "объединяющая" утилита (как в cvs, svn, git, gem) у которой первый
MY> параметр - команда, которую надо выполнить. Удобно, если есть умный
MY> комплишен а ля zsh или bash-completions, довольно неудобно, если нет.

Ага.

MY> Плюсы - наглядно, не надо запоминать практически ничего, кроме первых
MY> букв префикса.
MY> Минусы - чуть медленнее набирать, большая надежда на completion, надо
MY> продумывать так, чтобы удобно было комплитить и в completion попадали
MY> только нужные команды.
MY> Есть поклонники как одного стиля, так и другого. Поэтому, чтобы не
MY> мешать друг другу и не ломать копий - все равно это абсолютно вопрос
MY> привычки/удобства для конкретного человека - предлагаю сделать и так, и
MY> так - ровно как с опциями (-f и --force). Сделать симлинками или
MY> алиасами 2 варианта вызова - и длинный, и короткий.

Понимаешь... в любом случае upper case utilites это зло. Тем более что
всем этим утилитам место в основном в gear-.* namespace.

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

http://freesource.info
----------------------------------------------------------------------------
<shulik> что значит в спеке: %force_disable
<Ktirf> shulik: Отключение использования Великой Силы.

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

Re: [devel] Maintainer's toolbox

[Mikhail Yakshin]

Денис Смирнов пишет:
> On Fri, Feb 02, 2007 at 01:37:26AM +0300, Mikhail Yakshin wrote:
> 
>>> Ещё пока не выработалась схема по правильной работе с патчами в git.
>>> Вообще-то они должны быть в отдельных бранчах. Хранить патчи в виде патчей
>>> при использовании git это очень нехорошо.
> MY> Значит, нам нужен как минимум обратный инструмент - который после
> MY> srpmimport конвертит "Patch: ..." + "%patch-что-то-там", заводя их в git.
> 
> См. первую строчку моей цитаты. Выработается -- можно будет писать.

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

>>> Думаю скорее группа пакетов для разных workflow. Например gear-svnupdate
>>> не должен лежать там же где все остальное. Потому что он хочет svn,
>>> который не всем нужен.
> MY> Нам хотя бы один базовый пока набросать %)
> 
> Базовый не требует ни одной утилиты из отсутствующих в пакете gear, все
> остальное -- вариации на тему :)

Такой "базовый" не требует ничего, кроме бинарного редактора - все файлы 
можно отредактировать вручную, и TCP-пакеты тоже разослать %)

>>> Тогда вопрос о правильной схеме размещения. У меня, например, из-за обилия
>>> пакетов структура такая:
>>> git/ALTLinux -- там хранится все пакеты что я отправил на git.alt
>>> git/ALTLinux/asterisk -- все связаное с астериском
>>> git/ALTLinux/appliance -- appliance-*
>>> и т. д. Я не представляю как это сделать пригодным для всех способом.
> MY> Ok, понял, в ближайшее время сделаю такую возможность неплоского
> MY> размещения пакетов.
> MY> determine_package() переделаю так, чтобы он, если указан полный путь
> MY> (типа "ALTLinux/asterisk/some-package") - собирал бы его, если нет - то
> MY> искал бы соответствующую директорию find'ом; если найдена одна - то
> MY> собирал бы оттуда; если их несколько - то ругался бы на то, что не может
> MY> однозначно определить, что собирать (как rpm -e, когда под критерий
> MY> подпадает >1 пакета).
> 
> Разумно. Только с find'ом боюсь весело будет. Потому как в подкаталоги
> репозиториев смотреть не надо.

Ну, если будет тормозить - ограничим по -depth что-нибудь. Чтобы не 
хватал лишнего - будем следить, чтобы в каталоге репозитария был .git.

> MY> 2. Именовать, надеясь на комплишен. Имена тогда значительно длиннее и
> MY> максимально описательны. Возникает проблема completion space. Фактически
> MY> обязательно использование completion. Как правило, вводится некий
> MY> префикс наименования семейства утилит (git-*, gear-*, hsh-*, Sisyphus-*).
> 
> А вот фиг там. git-* вообще-то deprecated, надо пользоваться git *, к
> примеру. Вот как раз для удобного разделения completion namespace.

Ссылку на то, что он deprecated, кстати, можно? Там предлагается 
какая-то аргументация?

> MY> В качестве чуть альтернативной реализации - это когда делается одна
> MY> "объединяющая" утилита (как в cvs, svn, git, gem) у которой первый
> MY> параметр - команда, которую надо выполнить. Удобно, если есть умный
> MY> комплишен а ля zsh или bash-completions, довольно неудобно, если нет.
> 
> Ага.

Что-то мне подсказывает, что zsh сейчас у нас не default shell, да и 
даже bash-completions стоят хорошо если у трети народа.

> MY> Плюсы - наглядно, не надо запоминать практически ничего, кроме первых
> MY> букв префикса.
> MY> Минусы - чуть медленнее набирать, большая надежда на completion, надо
> MY> продумывать так, чтобы удобно было комплитить и в completion попадали
> MY> только нужные команды.
> MY> Есть поклонники как одного стиля, так и другого. Поэтому, чтобы не
> MY> мешать друг другу и не ломать копий - все равно это абсолютно вопрос
> MY> привычки/удобства для конкретного человека - предлагаю сделать и так, и
> MY> так - ровно как с опциями (-f и --force). Сделать симлинками или
> MY> алиасами 2 варианта вызова - и длинный, и короткий.
> 
> Понимаешь... в любом случае upper case utilites это зло.

Давай все-таки не смешивать. Есть 3 отдельные темы:

1) Стиль наименования утилит - нужен и "короткий", и "длинный". 
Согласен? У кого-то еще какие-то мнения есть?

2) Upper case для именования утилит. Твое мнение я понял, свое - 
озвучил, есть еще у кого-то какие-то мнения?

 > Тем более что всем этим утилитам место в основном в gear-.* namespace.

3) Предложение убрать разделение на утилиты "низкого уровня" вроде 
gear-*, hsh-* и т.п. и "высокого уровня" - те, что лежат в 
etersoft-build-utils / comfort? Я тогда его совсем не понимаю...

-- 
WBR, Mikhail Yakshin

Re: [devel] Maintainer's toolbox

[Michael Shigorin]

On Fri, Feb 02, 2007 at 12:21:37PM +0300, Mikhail Yakshin wrote:
> Что-то мне подсказывает, что zsh сейчас у нас не default shell,
> да и даже bash-completions стоят хорошо если у трети народа.

Кстати, для рабочей станции это стоило бы и поправить по
умолчанию.  Когда-то.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] I: gear-tarimport

[Led]

В сообщении от 27 января 2007 17:10 Mikhail Gusarov написал(a):
> AIF> > > Всё что прибито гвоздями - ограничивает свободу использования
> AIF> > > пакета.
> AIF> > И это хорошо - в этом и мысль.
> AIF> Неправильная мысль.
>
> +1. Неправильная. Поясню.
>
> Ограничение свободы сборщика пакета должно происходить только в одном
> случае: когда неограниченная свобода мешает совместимости. Если не
> следовать этому правилу, а насильно загонять в "светлое будущее", то
> все добровольные сборщики очень быстро разбегутся (что и наблюдается
> сейчас).
>
> Разбегутся по двум соображениям:
>
> 1) если сборщики не хотят идти в "светлое будущее" своими ногами, то
> это означает, что это "светлое будущее" либо недостаточно
> документировано, чтобы понять его "светлость", либо не настолько
> "светло".

Скорее, оно недостаточно аргументированно для рядового сборщика:)
"Централизация" - сорри, но лично для меня не аргумент.

>
> 2) Процесс применения административной силы при загоне показывает, что
> в коммунити все равны, но некоторые ровнее. Это заставляет понять, что
> добровольные сборщики являются de facto бесплатной рабочей силой для
> ООО, а кому это нравится?

Пока силой не загоняют в "светлое будущее git-централизации" - меня это даже 
не интересует (кто там как использует бесплатно), всё равно я собираю пакеты 
в большей степени для себя или для "хороших людей":)

-- 
Led.

Re: [devel] I: gear-tarimport

[Nick S. Grechukh]

> >> Будет исправлено. Хотя - с другой стороны - настолько гибким все делать
> >> - можно довести до абсурдных ситуаций - к каждой машине, например,
> >> задавать username,  почему бы не иметь
> >
> > А что в этом абсурдного? У меня на локальной машине и на сборочном сервере
> > разные username. Или  речь о другом?
>
> Речь об этом. В целом - это нетрадиционно и довольно неественно

ыыы, пешите ещо

Re: [devel] Maintainer's toolbox

[Денис Смирнов]

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

On Fri, Feb 02, 2007 at 12:21:37PM +0300, Mikhail Yakshin wrote:

>>>> Ещё пока не выработалась схема по правильной работе с патчами в git.
>>>> Вообще-то они должны быть в отдельных бранчах. Хранить патчи в виде патчей
>>>> при использовании git это очень нехорошо.
> MY>> Значит, нам нужен как минимум обратный инструмент - который после
> MY>> srpmimport конвертит "Patch: ..." + "%patch-что-то-там", заводя их в git.
>> См. первую строчку моей цитаты. Выработается -- можно будет писать.
MY> Ну, оно само по себе не выработается, если не будет некоего инструмента, 
MY> который бы фиксировал эту практику. То же самое, как сейчас бардак по 
MY> большому счету с выпускающими тэгами из-за отсутствия gear-release.

Ты её сначала придумай и документируй. Мне -- слабо.
Смотреть при этом рекомендую на новую систему сборки ядер, это
_единственный_ образец в сизифе более-менее удобной работы со множеством
патчей в отдельных бранчах.

>>>> Думаю скорее группа пакетов для разных workflow. Например gear-svnupdate
>>>> не должен лежать там же где все остальное. Потому что он хочет svn,
>>>> который не всем нужен.
> MY>> Нам хотя бы один базовый пока набросать %)
>> Базовый не требует ни одной утилиты из отсутствующих в пакете gear, все
>> остальное -- вариации на тему :)
MY> Такой "базовый" не требует ничего, кроме бинарного редактора - все файлы 
MY> можно отредактировать вручную, и TCP-пакеты тоже разослать %)

Ты преувеличиваешь.

Для базовой сборки пакетов достаточно gear, rpm-build и hasher. Это --
базовые утитилы. Остальное обертки.

Ещё есть etersoft-build-utils, которая обертка, но как раз оборачивает
наиболее частые действия. В общем-то сейчас я совершаю ой как мало
действий которые не автоматизируются этим набором. Когда вся сборка будет
через git, таких действий будет ровно 0.

Так что речь идет о высокоуровневых утилитках, или утилитках для
специфических _разных_ workflow для разных _особых_ задач. Как например
тот же svn-импорт.

>> Разумно. Только с find'ом боюсь весело будет. Потому как в подкаталоги
>> репозиториев смотреть не надо.
MY> Ну, если будет тормозить - ограничим по -depth что-нибудь. Чтобы не 
MY> хватал лишнего - будем следить, чтобы в каталоге репозитария был .git.

[mithraen@mw git]$ time find | wc -l
0.33user 1.06system 0:57.24elapsed 2%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+349minor)pagefaults 0swaps
187150

:)

Это при том что оно почти все в кэше, и там RAID 0+1.

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

> MY>> 2. Именовать, надеясь на комплишен. Имена тогда значительно длиннее и
> MY>> максимально описательны. Возникает проблема completion space. Фактически
> MY>> обязательно использование completion. Как правило, вводится некий
> MY>> префикс наименования семейства утилит (git-*, gear-*, hsh-*, Sisyphus-*).
>> А вот фиг там. git-* вообще-то deprecated, надо пользоваться git *, к
>> примеру. Вот как раз для удобного разделения completion namespace.
MY> Ссылку на то, что он deprecated, кстати, можно? Там предлагается 
MY> какая-то аргументация?

Это в этом листе озвучивал ldv@

> MY>> В качестве чуть альтернативной реализации - это когда делается одна
> MY>> "объединяющая" утилита (как в cvs, svn, git, gem) у которой первый
> MY>> параметр - команда, которую надо выполнить. Удобно, если есть умный
> MY>> комплишен а ля zsh или bash-completions, довольно неудобно, если нет.
>> Ага.
MY> Что-то мне подсказывает, что zsh сейчас у нас не default shell, да и 
MY> даже bash-completions стоят хорошо если у трети народа.

Это отдельная тема все-таки.

> MY>> Плюсы - наглядно, не надо запоминать практически ничего, кроме первых
> MY>> букв префикса.
> MY>> Минусы - чуть медленнее набирать, большая надежда на completion, надо
> MY>> продумывать так, чтобы удобно было комплитить и в completion попадали
> MY>> только нужные команды.
> MY>> Есть поклонники как одного стиля, так и другого. Поэтому, чтобы не
> MY>> мешать друг другу и не ломать копий - все равно это абсолютно вопрос
> MY>> привычки/удобства для конкретного человека - предлагаю сделать и так, и
> MY>> так - ровно как с опциями (-f и --force). Сделать симлинками или
> MY>> алиасами 2 варианта вызова - и длинный, и короткий.
>> Понимаешь... в любом случае upper case utilites это зло.
MY> Давай все-таки не смешивать. Есть 3 отдельные темы:
MY> 1) Стиль наименования утилит - нужен и "короткий", и "длинный". 
MY> Согласен? У кого-то еще какие-то мнения есть?
MY> 2) Upper case для именования утилит. Твое мнение я понял, свое - 
MY> озвучил, есть еще у кого-то какие-то мнения?
>> Тем более что всем этим утилитам место в основном в gear-.* namespace.
MY> 3) Предложение убрать разделение на утилиты "низкого уровня" вроде 
MY> gear-*, hsh-* и т.п. и "высокого уровня" - те, что лежат в 
MY> etersoft-build-utils / comfort? Я тогда его совсем не понимаю...

gear-* это не низкий уровень. Вообще-то это обертка над git и некоторыми
другими утилитами. Точно так же как etersoft-build-utils.


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

http://freesource.info
----------------------------------------------------------------------------
Т.к. Compact уже выпущен, то все что не успели исправить - ошибками
не считается.
		-- rider in #3005

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

Re: [devel] Maintainer's toolbox

[Mikhail Yakshin]

Michael Shigorin пишет:
> On Fri, Feb 02, 2007 at 12:21:37PM +0300, Mikhail Yakshin wrote:
>> Что-то мне подсказывает, что zsh сейчас у нас не default shell,
>> да и даже bash-completions стоят хорошо если у трети народа.
> 
> Кстати, для рабочей станции это стоило бы и поправить по
> умолчанию.  Когда-то.

Спорно, к сожалению. Я знаю ненулевое число людей, которые считают zsh 
настолько медленным, что не могут с ним работать.

-- 
WBR, GreyCat

Re: [devel] Maintainer's toolbox

[Mikhail Yakshin]

Денис Смирнов пишет:
> On Fri, Feb 02, 2007 at 12:21:37PM +0300, Mikhail Yakshin wrote:
> 
>>>>> Ещё пока не выработалась схема по правильной работе с патчами в git.
>>>>> Вообще-то они должны быть в отдельных бранчах. Хранить патчи в виде патчей
>>>>> при использовании git это очень нехорошо.
>> MY>> Значит, нам нужен как минимум обратный инструмент - который после
>> MY>> srpmimport конвертит "Patch: ..." + "%patch-что-то-там", заводя их в git.
>>> См. первую строчку моей цитаты. Выработается -- можно будет писать.
> MY> Ну, оно само по себе не выработается, если не будет некоего инструмента, 
> MY> который бы фиксировал эту практику. То же самое, как сейчас бардак по 
> MY> большому счету с выпускающими тэгами из-за отсутствия gear-release.
> 
> Ты её сначала придумай и документируй. Мне -- слабо.
> Смотреть при этом рекомендую на новую систему сборки ядер, это
> _единственный_ образец в сизифе более-менее удобной работы со множеством
> патчей в отдельных бранчах.

Хорошо, посмотрю.

>>>>> Думаю скорее группа пакетов для разных workflow. Например gear-svnupdate
>>>>> не должен лежать там же где все остальное. Потому что он хочет svn,
>>>>> который не всем нужен.
>> MY>> Нам хотя бы один базовый пока набросать %)
>>> Базовый не требует ни одной утилиты из отсутствующих в пакете gear, все
>>> остальное -- вариации на тему :)
> MY> Такой "базовый" не требует ничего, кроме бинарного редактора - все файлы 
> MY> можно отредактировать вручную, и TCP-пакеты тоже разослать %)
> 
> Ты преувеличиваешь.
> 
> Для базовой сборки пакетов достаточно gear, rpm-build и hasher. Это --
> базовые утитилы. Остальное обертки.

Боюсь, мы сейчас начнем какой-то высокофилософский спор и ни к чему не 
дойдем. Я могу поймать тебя на слове, где ты ниже говоришь, цитирую:

 > gear-* это не низкий уровень. Вообще-то это обертка

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

> Ещё есть etersoft-build-utils, которая обертка, но как раз оборачивает
> наиболее частые действия. В общем-то сейчас я совершаю ой как мало
> действий которые не автоматизируются этим набором. Когда вся сборка будет
> через git, таких действий будет ровно 0.

Ну, вот для меня ее явно не хватило именно в плане взаимодействия с git 
и появилось то, что появилось.

> Так что речь идет о высокоуровневых утилитках, или утилитках для
> специфических _разных_ workflow для разных _особых_ задач. Как например
> тот же svn-импорт.

Я попробую описать в ближайшее время некоторые примерные workflow, как я 
их себе представляю, ладно?

>>> Разумно. Только с find'ом боюсь весело будет. Потому как в подкаталоги
>>> репозиториев смотреть не надо.
> MY> Ну, если будет тормозить - ограничим по -depth что-нибудь. Чтобы не 
> MY> хватал лишнего - будем следить, чтобы в каталоге репозитария был .git.
> 
> [mithraen@mw git]$ time find | wc -l
> 0.33user 1.06system 0:57.24elapsed 2%CPU (0avgtext+0avgdata 0maxresident)k
> 0inputs+0outputs (0major+349minor)pagefaults 0swaps
> 187150
> 
> :)
> 
> Это при том что оно почти все в кэше, и там RAID 0+1.
> 
> На перловке я знаю как написать чтобы это работало (не обходить лишние
> каталоги), а вот как на шелле -- увы не знаю.

time find -maxdepth 3 | wc -l
?

>> MY>> 2. Именовать, надеясь на комплишен. Имена тогда значительно длиннее и
>> MY>> максимально описательны. Возникает проблема completion space. Фактически
>> MY>> обязательно использование completion. Как правило, вводится некий
>> MY>> префикс наименования семейства утилит (git-*, gear-*, hsh-*, Sisyphus-*).
>>> А вот фиг там. git-* вообще-то deprecated, надо пользоваться git *, к
>>> примеру. Вот как раз для удобного разделения completion namespace.
> MY> Ссылку на то, что он deprecated, кстати, можно? Там предлагается 
> MY> какая-то аргументация?
> 
> Это в этом листе озвучивал ldv@

ldv@, при всем моем уважении, насколько я знаю, не входит в число 
разработчиков-идеологов git. Можно ссылку на какую-то статью, roadmap, 
письмо в http://marc.theaimsgroup.com/?l=git или что-то такое, где 
официально заявляется о том, что они deprecated и будут убраны в 
таком-то релизе?

-- 
WBR, Mikhail Yakshin

Re: [devel] ~/.config/ (was gear-tarimport)

[Kirill Maslinsky]

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

On Wed, Jan 31, 2007 at 05:11:09PM +0300, Денис Смирнов wrote:
> rpmbb набрать быстрее чем любой вариант completion.

Это если не учитывать время, которое требуется на то, чтобы
сообразить, что именно сейчас нужно набрать. Есть основания
подозревать, что с учётом этого времени вариант с полнословным,
но прозрачным по смыслу completion для многих оказывается 
гораздо экономичнее ;)

-- 
Kirill Maslinsky
ALT Linux Documentation Team
http://heap.altlinux.ru

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

Re: [devel] ~/.config/ (was gear-tarimport)

[Денис Смирнов]

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

On Fri, Feb 02, 2007 at 10:06:08PM +0300, Kirill Maslinsky wrote:

>> rpmbb набрать быстрее чем любой вариант completion.
KM> Это если не учитывать время, которое требуется на то, чтобы
KM> сообразить, что именно сейчас нужно набрать. Есть основания
KM> подозревать, что с учётом этого времени вариант с полнословным,
KM> но прозрачным по смыслу completion для многих оказывается 
KM> гораздо экономичнее ;)

Не понял твою мысль. Можешь на пальцах пояснить?

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

http://freesource.info
----------------------------------------------------------------------------
Автором программы были выявлены недокументированные возможности...

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

Re: [devel] ~/.config/ (was gear-tarimport)

[Vitaly Lipatov]

On Wednesday 31 January 2007 13:47, Eugene Ostapets wrote:
...
> Цитата:http://standards.freedesktop.org/menu-spec/menu-spec-1.
>0.html If $XDG_CONFIG_HOME is not set, the default value of
> $HOME/.config should be used for it.
Ну и для полной понятности есть перевод
http://www.freesource.info/wiki/Standarts/XDGBaseDirectorySpecification

-- 
Lav
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! WINE! LaTeX! LyX! http://freesource.info

[devel] [JT] Re: Maintainer's toolbox

[Michael Shigorin]

On Fri, Feb 02, 2007 at 06:16:36PM +0300, Mikhail Yakshin wrote:
> >> Что-то мне подсказывает, что zsh сейчас у нас не default shell,
> >> да и даже bash-completions стоят хорошо если у трети народа.
> > Кстати, для рабочей станции это стоило бы и поправить по
> > умолчанию.  Когда-то.
> Спорно, к сожалению. Я знаю ненулевое число людей, которые
> считают zsh настолько медленным, что не могут с ним работать.

OK, тогда "считаю данный выбор в инсталере важнее dump order!" :)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] Maintainer's toolbox

[Денис Смирнов]

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

On Fri, Feb 02, 2007 at 06:31:38PM +0300, Mikhail Yakshin wrote:

> MY>> Ну, оно само по себе не выработается, если не будет некоего инструмента, 
> MY>> который бы фиксировал эту практику. То же самое, как сейчас бардак по 
> MY>> большому счету с выпускающими тэгами из-за отсутствия gear-release.
>> Ты её сначала придумай и документируй. Мне -- слабо.
>> Смотреть при этом рекомендую на новую систему сборки ядер, это
>> _единственный_ образец в сизифе более-менее удобной работы со множеством
>> патчей в отдельных бранчах.
MY> Хорошо, посмотрю.

Получилось что-нибудь?

> MY>> Такой "базовый" не требует ничего, кроме бинарного редактора - все файлы 
> MY>> можно отредактировать вручную, и TCP-пакеты тоже разослать %)
>> Ты преувеличиваешь.
>> Для базовой сборки пакетов достаточно gear, rpm-build и hasher. Это --
>> базовые утитилы. Остальное обертки.
MY> Боюсь, мы сейчас начнем какой-то высокофилософский спор и ни к чему не 
MY> дойдем. Я могу поймать тебя на слове, где ты ниже говоришь, цитирую:
>> gear-* это не низкий уровень. Вообще-то это обертка
MY> и тем самым противоречишь сам себе. Не суть важно, я не хочу сейчас 
MY> бросаться словами и делить все на черное и белое, на двухуровневое, на 
MY> "плохое-хорошее", "высокоуровневое-низкоуровневое" и т.п. Так мы только 
MY> поругаемся и ничего не решим.

Это было в тему наименований утилит, если мне правильно помнится.

Так вот, возвращаясь к теме, исходить лучше из того, под каким именем ты
бы ожидал увидеть эту утилиту будучи пьян в стельку до степени
неспособности выговорить вслух слово "sisyphus". Если даже в таком
состоянии можно правильно вспомнить и набрать это название -- значит оно
было удачным :)

>> Так что речь идет о высокоуровневых утилитках, или утилитках для
>> специфических _разных_ workflow для разных _особых_ задач. Как например
>> тот же svn-импорт.
MY> Я попробую описать в ближайшее время некоторые примерные workflow, как я 
MY> их себе представляю, ладно?

Опять же, удалось? Задача нелегкая, а результат её ценен для всех.

>> [mithraen@mw git]$ time find | wc -l
>> 0.33user 1.06system 0:57.24elapsed 2%CPU (0avgtext+0avgdata 0maxresident)k
>> 0inputs+0outputs (0major+349minor)pagefaults 0swaps
>> 187150
>> :)
>> Это при том что оно почти все в кэше, и там RAID 0+1.
>> На перловке я знаю как написать чтобы это работало (не обходить лишние
>> каталоги), а вот как на шелле -- увы не знаю.
MY> time find -maxdepth 3 | wc -l
MY> ?

Оно не покажет все мои репозитории. Ага, я псих и маньяк. Правда думаю мы
оба понимаем что лучше если утилита будет работать для 90% людей (которые
не маньяки в конкретной области), лишь бы степень взаимосвязанности утилит
при любом шаге в сторону от партийной линии не мешала пользоваться всем
комплектом.

>> MY>>> 2. Именовать, надеясь на комплишен. Имена тогда значительно длиннее и
>> MY>>> максимально описательны. Возникает проблема completion space. Фактически
>> MY>>> обязательно использование completion. Как правило, вводится некий
>> MY>>> префикс наименования семейства утилит (git-*, gear-*, hsh-*, Sisyphus-*).
>>>> А вот фиг там. git-* вообще-то deprecated, надо пользоваться git *, к
>>>> примеру. Вот как раз для удобного разделения completion namespace.
> MY>> Ссылку на то, что он deprecated, кстати, можно? Там предлагается 
> MY>> какая-то аргументация?
>> Это в этом листе озвучивал ldv@
MY> ldv@, при всем моем уважении, насколько я знаю, не входит в число 
MY> разработчиков-идеологов git. Можно ссылку на какую-то статью, roadmap, 
MY> письмо в http://marc.theaimsgroup.com/?l=git или что-то такое, где 
MY> официально заявляется о том, что они deprecated и будут убраны в 
MY> таком-то релизе?

Тут все вопросы к Диме. Увы, у меня нет времени на внимательное
отслеживание апстрима ещё и git. А по пакетам в которых у меня нет времени
досконально разобраться я предпочитаю брать на веру слова тех, в знаниях
которых я более-менее уверен. Касаемо git это ldv@ и vsu@.

Ну и в целом я сам согласен с тем, что чем меньше всего в глобальном name
space, тем лучше.

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

http://freesource.info
----------------------------------------------------------------------------
Настоящий программист уже как минимум поменял три залитых пивом клавиатуры.

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