| 1 |
В Пнд, 23/04/2007 в 14:27 +0400, Vladimir Solomatin пишет:
|
| 2 |
> ну а по поводу OpenOffice.org |
| 3 |
> |
| 4 |
> допустим! |
| 5 |
> # cat openoffice-2.1.0-r1.ebuild | grep KEYWORDS |
| 6 |
> KEYWORDS="~amd64 ppc -sparc x86" |
| 7 |
> т.е. в x86 стабильная в ~amd64 (пусть не собирается). |
| 8 |
> потом пофиксили проблему для amd64 |
| 9 |
> |
| 10 |
> # cat openoffice-2.1.0-r2.ebuild | grep KEYWORDS |
| 11 |
> KEYWORDS="amd64 ~ppc -sparc ~x86" |
| 12 |
> |
| 13 |
> все. -r1 так и останется нестабильной для amd64, а -r2 будет прекрасно |
| 14 |
> работать. остальные архитектуры это ни коим образом не затронет. |
| 15 |
> |
| 16 |
> Почему я считаю что так правильно? Любая правка может потенциально |
| 17 |
> влиять пакет для всех архитектур. Люди пишут программы.. люди ошибаются. |
| 18 |
> Люди исправляют ошибки.. какова вероятность того что не ошибется и в |
| 19 |
> этот раз? |
| 20 |
|
| 21 |
Вы почти правы и для стабильной ветки подобные вещи стараются делать как
|
| 22 |
можно реже. Но, что делать если пакет уже попал в стабильную ветку а
|
| 23 |
после этого обнаружили, что при некоторой комбинации USE флагов он не
|
| 24 |
собирается? Прибавить ревизию и ждать месяц в том время как стабильный
|
| 25 |
ebuild сломан?
|
| 26 |
|
| 27 |
Потом, всё-равно не вижу смысла прибавлять ревизию в случае не
|
| 28 |
функциональной правки. А в случае с openoffice ради интереса посмотрите
|
| 29 |
ChangeLog ;)
|
| 30 |
|
| 31 |
> К тому же офлайн установку/обновление (когда сети нет физически!) не |
| 32 |
> получается сделать из-за того что отсутствует какой-то файлик на пару |
| 33 |
> килобайт. Приходится делать 'emerge -ef world' перед копирование disfiles. |
| 34 |
|
| 35 |
gentoo никогда не позиционировался как идеальный дистрибутив для offline
|
| 36 |
установки, хотя он позволяет делать и это... Кстати, потрудитесь,
|
| 37 |
поищите по форумам и gentoo-wiki.com. Где-то я встречал, какие-то
|
| 38 |
оптимизации для этого процесса, но лично мне это никогда не нужно
|
| 39 |
было...
|
| 40 |
|
| 41 |
> > [1] http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3&chap=1#doc_chap3 |
| 42 |
> |
| 43 |
> может я как-то не так читаю, но то о чем вы говорите, я не нашел.. |
| 44 |
|
| 45 |
Просто я не могу вам дать ссылку на подпункт... параграфом ниже:
|
| 46 |
|
| 47 |
Versioning and revision bumps
|
| 48 |
|
| 49 |
Package revision numbers should be incremented by Gentoo Linux
|
| 50 |
developers when the ebuild has changed to the point where users would
|
| 51 |
want to upgrade. Typically, this is the case when fixes are made to an
|
| 52 |
ebuild that affect the resultant installed files, but the ebuild uses
|
| 53 |
the same source tarball as the previous release. If you make an
|
| 54 |
internal, stylistic change to the ebuild that does not change any of the
|
| 55 |
installed files, then there is no need to bump the revision number.
|
| 56 |
Likewise, if you fix a compilation problem in the ebuild that was
|
| 57 |
affecting some users, there is no need to bump the revision number,
|
| 58 |
since those for whom it worked perfectly would see no benefit in
|
| 59 |
installing a new revision, and those who experienced the problem do not
|
| 60 |
have the package installed (since compilation failed) and thus have no
|
| 61 |
need for the new revision number to force an upgrade. A revision bump is
|
| 62 |
also not necessary if a minority of users will be affected and the
|
| 63 |
package has a nontrivial average compilation time; use your best
|
| 64 |
judgement in these circumstances.
|
| 65 |
|
| 66 |
--
|
| 67 |
Peter. |
Archives