gug-bg-herd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Проблем с aspell-bg/bgoffice


From: Yavor Doganov
Subject: Re: Проблем с aspell-bg/bgoffice
Date: Sun, 25 Jul 2010 09:24:10 +0300
User-agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (Gojō) APEL/10.7 Emacs/23.2 (i486-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)

Ивайло Вълков wrote:
> > It seems this is done unconditionally in postrm.  The attached patch
> > works for me;
> >    
> 
> Да разбирам ли, че това (временно?) оправя проблема?

Според мен кръпката изцяло коригира проблема.  Тествах интензивно.

> Друг е въпросът дали изобщо има смисъл от разделяне.

Това зависи изцяло от upstream.  Не съм гледал конкретно съдържанието,
разпределението и датите на изданията, но ми се струваше тогава, че
bgoffice-4.1 е последната версия вкупом, след това имаше май няколко
издания разделени.  Така че ако upstream са започнали да ги издават
само разделно, значи и Дебиан ще ги пакетира разделно.

По принцип няма голямо значение, просто технически подробности.

> Изобщо обновяването до нова версия и евентуално разделяне на пакетите 
> може ли да се реализира без някой да поема пакета

Да, понеже пакетът е изоставен, всеки може да го направи под формата
на т.нар. „QA upload“.  Ако не си DD, ти трябва спонсор (както и ако
си официален отговорник).

> – чрез доклади за грешки и кръпки?

Доклади за грешки + кръпки върши работа при сериозни грешки.  Все ще
се намери някой да ги приложи, дори и ако пакета има отговорник, но
бездейства (чрез NMU -- non-maintainer upload).  Разделянето на пакета
и други действия, козметични или не, трудно ще стане чрез доклади за
грешки, понеже са твърде малко хората, които ще им обърнат внимание.

> Ако не за момента става безмислено да разучавам повече (и
> документация).

Можеш да поддържаш пакета без да се цаниш за отговорник, но всеки,
който поиска да го поеме, има правото да го направи без да се
съобразява с теб.  По принцип, ако не си сигурен в себе си (технически
възможности, свободно време, траен интерес към пакета и т.н.), това е
добра тактика -- „де факто“ поддържаш изоставен пакет известно време,
но го „осиновяваш де юре“ чак когато се почувстваш готов.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]