opensolaris pkgsrc nbpatch libtool-base-1.5.26nb2

[Vova Uralsky]

Hi All!

Собираю libtool-base, вродк всё сделал как написано вот здесь:
http://blogs.sun.com/jperkin/entry/pkgsrc_on_solaris... Вылетает на
патче. Если сказать bmake -dl видно следующее:

=> Applying pkgsrc patches for libtool-base-1.5.26nb2
set -e; fail=;

patches=/usr/pkgsrc/devel/libtool-base/../libtool/patches/patch-\*;
patch_wa
rning() { echo
"**************************************"; echo "$1";
echo
"**************************************"; };
for i in $patches; do
test -f "$i" || continue;
case "$i" in
*.orig|*.rej|*~)
echo "=>" "Ignoring patchfile $i";
continue; ;;

/usr/pkgsrc/devel/libtool-base/../libtool/patches/patch-local-*)
;;
/usr/pkgsrc/devel/libtool-base/../libtool/patches/patch-
*|/usr/pkgsrc/devel/libtool-base/../libtool/patches/emul-*-patch-*)
if test ! -f /usr/pkgsrc/devel/libtool-ba
se/../libtool/distinfo; then patch_warning "Ignoring patch file $i:
distinfo not found"; continue;
fi; echo >/dev/null
'***' "Verifying $i"; if /usr/bin/env
DIGEST=/usr/pkg/bin/digest CAT=/usr/bin/cat ECHO=echo
SED=/usr/pkg/bin/nbsed TEST=test
/usr/pkg/bin/pdksh
/usr/pkgsrc/mk/checksum/checksum -p /usr/pkgsrc/devel/libtool-b
ase/../libtool/distinfo $i >/dev/null 2>&1; then cksum_result=0;
else
cksum_result=$?; fi;
case "$cksum_result" in 0) ;;
2) patch_warning "Ign
oring patch file $i: no checksum found"; continue ;;
1) patch_warning "Ignoring patch file
$i: invalid checksum"; fail="$fail $i"; continue
;; esac;
;;
esac;
echo >/dev/null '***' "Applying pkgsrc patch $i";
fuzz_flags=;
if /usr/pkg/bin/nbpatch -v >/dev/null 2>&1; then
fuzz_flags=-F0;
fi; if
/usr/pkg/bin/nbpatch $fuzz_flags -d /usr/pkgsrc/devel/libtool-
base/work/libtool-1.5.26 --forward --quiet -E -p0 -V simple -z .orig <
$i; then echo "$i" >> /usr/pkgsrc/devel/lib
tool-base/work/.patch; else
echo "Patch $i failed";
fail="$fail $i"; fi;
done; if test
-n "$fail"; then
echo 1>&2 "ERROR:" "Patching failed due to modified or broken
patch file(s):"; for i in $fail; do
echo 1>&2 "ERROR:" " $i";
done;
if test -n "" ||
test -n "" -a -d /devel/libtool-base; then echo
1>&2 "ERROR:"
"==========================================================================";
echo 1>&2 "ERROR:";
echo 1>&2 "ERROR:"
"Some of the selected build options and/or local patc
hes may be incompatible."; echo 1>&2 "ERROR:" "Please try building with
fewer options or patches."; echo 1>&2 "ERROR:";
echo 1>&2
"ERROR:" "==============================================
============================"; fi; exit 1;
fi
patch: **** too many file arguments
Patch /usr/pkgsrc/devel/libtool-base/../libtool/patches/patch-aa failed
patch: **** too many file arguments
Patch /usr/pkgsrc/devel/libtool-base/../libtool/patches/patch-ab failed
patch: **** too many file arguments
Patch /usr/pkgsrc/devel/libtool-base/../libtool/patches/patch-ac failed
patch: **** too many file arguments
Patch /usr/pkgsrc/devel/libtool-base/../libtool/patches/patch-ad failed
ERROR: Patching failed due to modified or broken patch file(s):
ERROR: /usr/pkgsrc/devel/libtool-base/../libtool/patches/patch-aa
ERROR: /usr/pkgsrc/devel/libtool-base/../libtool/patches/patch-ab
ERROR: /usr/pkgsrc/devel/libtool-base/../libtool/patches/patch-ac
ERROR: /usr/pkgsrc/devel/libtool-base/../libtool/patches/patch-ad
*** Error code 1

Stop.

Гугление дает единственную ссылку:
http://mail-index.netbsd.org/pkgsrc-users/2009/10/13/msg010972.html

Ручками патчи прекрасно прикладываются. После touch .patch_done
собирается дальше. Но нехорошо это как-то... Вопросы, как обычно, "Что
делать и кто виноват?"

Vova

[Ilya Kulagin]

Tue Nov 10 2009 11:07, Vova Uralsky wrote to All:

VU> Ручками патчи прекрасно прикладываются. После touch .patch_done
VU> собирается дальше.
VU> о нехорошо это как-то... Вопросы, как обычно, "Что
VU> делать и кто виноват?"

Предметно не скажу. Hо похожие баги преодолевал, указывая шелом баш и первым в
путях ставя /usr/gnu/bin .

/kiv

[Vova Uralsky]

Hi!

Ilya Kulagin -> Vova Uralsky wrote:
VU>> Ручками патчи прекрасно прикладываются. После touch .patch_done
VU>> собирается дальше.
VU>> о нехорошо это как-то... Вопросы, как обычно, "Что
VU>> делать и кто виноват?"
IK> Предметно не скажу. Hо похожие баги преодолевал, указывая шелом баш и
IK> первым в
IK> путях ставя /usr/gnu/bin .

Не, не оно

$ echo $SHELL $PATH
/usr/bin/bash
/usr/pkg/bin:/usr/pkg/sbin:/usr/gnu/bin:/usr/bin:/usr/X11/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/sbin

Ругается-то nbpatch собственной персоной...

Вот, вытащил 2009Q2, посмотрим, как оно, может это только в Q3 такая беда.

Vova

[Aleksey Cheusov]

VU> patch: **** too many file arguments
VU> Patch /usr/pkgsrc/devel/libtool-base/../libtool/patches/patch-aa failed
VU> patch: **** too many file arguments
VU> Patch /usr/pkgsrc/devel/libtool-base/../libtool/patches/patch-ab failed
VU> patch: **** too many file arguments
VU> Patch /usr/pkgsrc/devel/libtool-base/../libtool/patches/patch-ac failed
VU> patch: **** too many file arguments
VU> Patch /usr/pkgsrc/devel/libtool-base/../libtool/patches/patch-ad failed
VU> ERROR: Patching failed due to modified or broken patch file(s):
VU> ERROR: /usr/pkgsrc/devel/libtool-base/../libtool/patches/patch-aa
VU> ERROR: /usr/pkgsrc/devel/libtool-base/../libtool/patches/patch-ab
VU> ERROR: /usr/pkgsrc/devel/libtool-base/../libtool/patches/patch-ac
VU> ERROR: /usr/pkgsrc/devel/libtool-base/../libtool/patches/patch-ad
VU> *** Error code 1

VU> Stop.

VU> Гугление дает единственную ссылку:
VU> http://mail-index.netbsd.org/pkgsrc-users/2009/10/13/msg010972.html

VU> Ручками патчи прекрасно прикладываются.

А что говорит

/usr/pkg/bin/nbpatch -А0 -d \
/usr/pkgsrc/devel/libtool-base/work/libtool-1.5.26 \
--forward --quiet -E -p0 -V simple -z .orig < \
/usr/pkgsrc/devel/libtool-base/../libtool/patches/patch-ad

[Vova Uralsky]

Hi!

Aleksey Cheusov -> Vova Uralsky wrote:
VU>> patch: **** too many file arguments
VU>> Patch /usr/pkgsrc/devel/libtool-base/../libtool/patches/patch-ad
VU>> failed
AC> А что говорит
AC> /usr/pkg/bin/nbpatch -А0 -d \
AC> /usr/pkgsrc/devel/libtool-base/work/libtool-1.5.26 \
AC> --forward --quiet -E -p0 -V simple -z .orig < \
AC> /usr/pkgsrc/devel/libtool-base/../libtool/patches/patch-ad

$ pfexec /usr/pkg/bin/nbpatch -A0 -d
/usr/pkgsrc/devel/libtool-base/work/libtool-1.5.26 --forward --quiet -E
-p0 -V simple -z .orig <
/usr/pkgsrc/devel/libtool-base/../libtool/patches/patch-ad
/usr/pkg/bin/nbpatch: illegal option -- A
usage: patch [-bCcEeflNnRstuv] [-B backup-prefix] [-D symbol] [-d directory]
[-F max-fuzz] [-i patchfile] [-o out-file] [-p strip-count]
[-r rej-name] [-V t | nil | never] [-x number] [-z backup-ext]
[--posix] [origfile [patchfile]]
patch <patchfile

Тут, видимо, опечатка, не -A0, а -F0 (max-fuzz)

$ pfexec /usr/pkg/bin/nbpatch -F0 -d
/usr/pkgsrc/devel/libtool-base/work/libtool-1.5.26 --forward --quiet -E
-p0 -V simple -z .orig <
/usr/pkgsrc/devel/libtool-base/../libtool/patches/patch-ad
patch: **** too many file arguments

Vova

[Aleksey Cheusov]

VU> Тут, видимо, опечатка, не -A0, а -F0 (max-fuzz)
Да.

VU> $ pfexec /usr/pkg/bin/nbpatch -F0 -d
VU> /usr/pkgsrc/devel/libtool-base/work/libtool-1.5.26 --forward --quiet -E
VU> -p0 -V simple -z .orig <
VU> /usr/pkgsrc/devel/libtool-base/../libtool/patches/patch-ad
VU> patch: **** too many file arguments

А

/usr/pkgsrc/devel/libtool-base/work/libtool-1.5.26 -N -s -E
-p0 -V simple -z .orig <
/usr/pkgsrc/devel/libtool-base/../libtool/patches/patch-ad

работает (все опции короткие) ?

[Aleksey Cheusov]

VU> Тут, видимо, опечатка, не -A0, а -F0 (max-fuzz)
Да.

VU> $ pfexec /usr/pkg/bin/nbpatch -F0 -d
VU> /usr/pkgsrc/devel/libtool-base/work/libtool-1.5.26 --forward --quiet -E
VU> -p0 -V simple -z .orig <
VU> /usr/pkgsrc/devel/libtool-base/../libtool/patches/patch-ad
VU> patch: **** too many file arguments

А

/usr/pkg/bin/nbpatch -F0 -d \
/usr/pkgsrc/devel/libtool-base/work/libtool-1.5.26 -N -s -E \
-p0 -V simple -z .orig <
/usr/pkgsrc/devel/libtool-base/../libtool/patches/patch-ad

работает (все опции короткие) ?

[Vova Uralsky]

Hi!

Aleksey Cheusov -> Vova Uralsky wrote:
AC> А
AC> /usr/pkg/bin/nbpatch -F0 -d \
AC> /usr/pkgsrc/devel/libtool-base/work/libtool-1.5.26 -N -s -E \
AC> -p0 -V simple -z .orig <
AC> /usr/pkgsrc/devel/libtool-base/../libtool/patches/patch-ad
AC> работает (все опции короткие) ?

Нет, эффект тот же.

Vova

[Aleksey Cheusov]

VU> Hi!

VU> Aleksey Cheusov -> Vova Uralsky wrote:
AC>> А
AC>> /usr/pkg/bin/nbpatch -F0 -d \
AC>> /usr/pkgsrc/devel/libtool-base/work/libtool-1.5.26 -N -s -E \
AC>> -p0 -V simple -z .orig <
AC>> /usr/pkgsrc/devel/libtool-base/../libtool/patches/patch-ad
AC>> работает (все опции короткие) ?

VU> Hет, эффект тот же.

В общем, где искать ошибку вполне ясно, но ping-pong - это долго.
Соляры у меня под рукой сейчас нет, так что придется тебе таки
"писать в спорт лото".

И libnbcompat и nbpatch находятся фактически в ведении
Joerg Sonnenberger-а,
так что можешь вмело писать непосредственно ему.

[Aleksey Cheusov]

VU> Гугление дает единственную ссылку:
VU> http://mail-index.netbsd.org/pkgsrc-users/2009/10/13/msg010972.html

Если никто не ответил в pkgsrc-users@, можно отфорвардить в pkg-tech@
или написать PR, если еще нет.

[Vova Uralsky]

Hi!

Aleksey Cheusov -> Vova Uralsky wrote:
VU>> Гугление дает единственную ссылку:
VU>> http://mail-index.netbsd.org/pkgsrc-users/2009/10/13/msg010972.html
AC> Если никто не ответил в pkgsrc-users@, можно отфорвардить в pkg-tech@
AC> или написать PR, если еще нет.

Не, в спортлото еще не писал. Меня не оставляет ощущение что это
какая-то локальная заморочка. Какая-то странная кривизна бутстрапа.

Vova

[Aleksey Cheusov]

VU> Aleksey Cheusov -> Vova Uralsky wrote:
VU>>> Гугление дает единственную ссылку:
VU>>> http://mail-index.netbsd.org/pkgsrc-users/2009/10/13/msg010972.html
AC>> Если никто не ответил в pkgsrc-users@, можно отфорвардить в pkg-tech@
AC>> или написать PR, если еще нет.

VU> Hе, в спортлото еще не писал. Меня не оставляет ощущение что это
VU> какая-то локальная заморочка. Какая-то странная кривизна бутстрапа.

См. мое соседнее письмо насчет коротких опций.
Ошибка точно не в бутстрапе. Скорее в сборке devel/nbpatch и/или
реализации getopt_long.c из pkgtools/libnbcompat

[Vova Uralsky]

Hi!

Aleksey Cheusov -> Vova Uralsky wrote:
VU>> Hе, в спортлото еще не писал. Меня не оставляет ощущение что это
VU>> какая-то локальная заморочка. Какая-то странная кривизна бутстрапа.
AC> См. мое соседнее письмо насчет коротких опций.
AC> Ошибка точно не в бутстрапе. Скорее в сборке devel/nbpatch и/или
AC> реализации getopt_long.c из pkgtools/libnbcompat

Ну, примерно это я и имел в виду. gcc я уже собрал, осталось собрать
binutils и пересобрать этим делом то что собирает bootstrap.

Нашел еще кое-что:
http://www.skytale.net/blog/archives/17-Using-pkgsrc-on-Opensolaris,-Part-3.html,
читать с "Patching gcc", может это поможет.

Vova

[Aleksey Cheusov]

VU>>> Hе, в спортлото еще не писал. Меня не оставляет ощущение что это
VU>>> какая-то локальная заморочка. Какая-то странная кривизна бутстрапа.
AC>> См. мое соседнее письмо насчет коротких опций.
AC>> Ошибка точно не в бутстрапе. Скорее в сборке devel/nbpatch и/или
AC>> реализации getopt_long.c из pkgtools/libnbcompat

VU> Hу, примерно это я и имел в виду. gcc я уже собрал, осталось собрать
VU> binutils и пересобрать этим делом то что собирает bootstrap.

К ошибкам nbpatch и/или libnbcompat gcc/binutils почти наверняка
никакого отношения не имеет. Я бы жаловался в спорт-лото.

VU> Hашел еще кое-что:
VU> http://www.skytale.net/blog/archives/17-Using-pkgsrc-on-Opensolaris,-Part-3.html,
VU> читать с "Patching gcc", может это поможет.

Кстати говоря. Если плюнуть на кривой nbpatch (Пусть другие шлют письма
в спорт-лото ;-) ), то вот это вполне вариант.

TOOLS_PLATFORM.patch= /usr/bin/gpatch
TOOLS_PLATFORM.gpatch= /usr/bin/gpatch

И вообще обратить внимание на другие TOOLS_PLATFORM.xxx.

[Vova Uralsky]

Hi!

Aleksey Cheusov -> Vova Uralsky wrote:
AC> Кстати говоря. Если плюнуть на кривой nbpatch (Пусть другие шлют письма
AC> в спорт-лото ;-) ), то вот это вполне вариант.
AC> TOOLS_PLATFORM.patch= /usr/bin/gpatch
AC> TOOLS_PLATFORM.gpatch= /usr/bin/gpatch

Оно уже там:

pkgsrc/mk/tools/tools.SunOS.mk:
......
..if exists(/usr/bin/gpatch)
TOOLS_PLATFORM.patch?= /usr/bin/gpatch
..endif
......

AC> И вообще обратить внимание на другие TOOLS_PLATFORM.xxx.

:-)

Vova

[Vova Uralsky]

Hi All!

Aleksey Cheusov навел на абсолютно правильную мысль. А именно, посмотреть в
mk/. Видимо этот nbpatch и не должен на саносях работать.

Тереь немного к причинам возникновения проблемы. Дело в том что в opensolaris
sparse зон нет, и, видимо, не будет. Новые зоны, хоть и являютя полными, не
содержат всех пакетов, установленных в global. Они даже не являются native:

$ zoneadm list -cv
ID NAME STATUS PATH BRAND IP
0 global running / native shared
1 delme running /zones/delme ipkg shared

Зона содержит только минимальный набор пакетов. Мотивация была, видимо, не
размножать гномов, не нервировать публику. Так получилось что набор пакетов
установленных в зону не содержит никакой гнушности, которую ожидает pkgsrc.
Доустановить SUNWgcc еще в голову приходит, а остальное... Вобщем, такое
происходит только в зоне и только в opensolaris. А г-ну Зонненбергеру я
обязательно напишу. Теперь хоть понятно что писать. :-)

Vova Uralsky -> Aleksey Cheusov schrieb:
VU> Aleksey Cheusov -> Vova Uralsky wrote:
AC>> Кстати говоря. Если плюнуть на кривой nbpatch (Пусть другие шлют
AC>> письма
AC>> в спорт-лото ;-) ), то вот это вполне вариант.
AC>> TOOLS_PLATFORM.patch= /usr/bin/gpatch
AC>> TOOLS_PLATFORM.gpatch= /usr/bin/gpatch
VU> Оно уже там:
VU> pkgsrc/mk/tools/tools.SunOS.mk:
VU> .....
VU> .if exists(/usr/bin/gpatch)
VU> TOOLS_PLATFORM.patch?= /usr/bin/gpatch
VU> .endif
VU> .....

$ ls /usr/bin/gpatch
/usr/bin/gpatch: No such file or directory
$ pfexec pkg install SUNWgpch
DOWNLOAD PKGS FILES XFER (MB)
Completed 1/1 3/3 0.06/0.06

PHASE ACTIONS
Install Phase 23/23
$ ls /usr/bin/gpatch
/usr/bin/gpatch
$ cd /usr/pkgsrc/devel/libtool-base/
$ pfexec bmake clean
===> Cleaning for libtool-base-1.5.26nb1
$ pfexec bmake > /dev/null && echo it works\!
WARNING: No /var/db/pkg/pkg-vulnerabilities file found.
WARNING: To fix run: `/usr/pkg/sbin/pkg_admin -K /var/db/pkg
fetch-pkg-vulnerabilities'.
configure: WARNING: If you wanted to set the --build type, don't use --host.
If a cross compiler is detected then cross compile mode will be used.
configure: WARNING: If you wanted to set the --build type, don't use --host.
If a cross compiler is detected then cross compile mode will be used.
it works!
$ uname -a
SunOS osol 5.11 snv_111b i86pc i386 i86pc Solaris

Vova

[Ilya Kulagin]

Thu Nov 12 2009 21:35, Vova Uralsky wrote to Vova Uralsky:

VU> opensolaris sparse зон нет, и, видимо, не будет. овые зоны, хоть и
VU> являютя полными, не содержат всех пакетов, установленных в global. Они
VU> даже не являются native:

VU> $ zoneadm list -cv
VU> ID NAME STATUS PATH BRAND
VU> IP
VU> 0 global running / native
VU> shared
VU> 1 delme running /zones/delme ipkg
VU> shared

Информация к размышлению:
sun[root]~/> zoneadm list -cv
ID NAME STATUS PATH BRAND IP

0 global running / native
shared
1 orcl running /zones/orcl native excl

2 inet running /zones/inet native
shared
sun[root]~/> uname -a
SunOS sun 5.11 snv_126 i86pc i386 i86xpv

Это sxce.

/kiv

[Vova Uralsky]

Hi!

Ilya Kulagin -> Vova Uralsky wrote:
VU>> даже не являются native:
VU>> $ zoneadm list -cv
VU>> 1 delme running /zones/delme ipkg
IK> Информация к размышлению:
sun[root]~/>> zoneadm list -cv
IK> 1 orcl running /zones/orcl native
sun[root]~/>> uname -a
IK> SunOS sun 5.11 snv_126 i86pc i386 i86xpv
IK> Это sxce.

Вот и верь после этого людям. ;-) Сначала зубы заговаривали, типа,
native только то, что установлено через pkgadd, а что установлено через
pkg install будет ipkg. И что ipkg кульнее, поскольку независимо от
global, не патчится вместе с global итд. Интересно, каким способом оно у
тебя установлено? Ну и если несложно, покажи пож-та zonecfg -z orcl export

Vova

[Ilya Kulagin]

Fri Nov 13 2009 11:33, Vova Uralsky wrote to Ilya Kulagin:

IK>> Это sxce.

^^^^^^^^ - именно в этом и корень вопроса :)

VU> Вот и верь после этого людям. ;-) Сначала зубы заговаривали, типа,
VU> native только то, что установлено через pkgadd, а что установлено через
VU> pkg install будет ipkg. И что ipkg кульнее, поскольку независимо от
VU> global, не патчится вместе с global итд. Интересно, каким способом оно у
VU> тебя установлено?

Через pkgadd, конечно :) Судя по тому, как продвигается грядущее в декабре
слияние opensolaris и sxce, нам предстоит делать SVR4 package из ipkg, а то
обучать pkg всему, что умеет pkgadd будут ещё долго.

VU> у и если несложно, покажи пож-та zonecfg -z orcl export

create -b
set zonepath=/zones/orcl
set autoboot=true
set limitpriv=default,sys_smb
set ip-type=exclusive
add inherit-pkg-dir
set dir=/lib
end
add inherit-pkg-dir
set dir=/platform
end
add inherit-pkg-dir
set dir=/sbin
end
add inherit-pkg-dir
set dir=/usr
end
add inherit-pkg-dir
set dir=/opt
end
add fs
set dir=/util
set special=/exports/util
set type=lofs
end
add fs
set dir=/exports
set special=/exports/project
set type=lofs
end
add net
set physical=igb1001
end
add net
set physical=igb2001
end
add net
set physical=igb3001
end
add net
set physical=igb4001
end
add net
set physical=igb5001
end
add net
set physical=vnic0
end
add net
set physical=vnic2
end
add rctl
set name=zone.max-lwps
add value (priv=privileged,limit=5000,action=deny)
end
add rctl
set name=zone.cpu-shares
add value (priv=privileged,limit=50,action=none)
end
add rctl
set name=zone.max-swap
add value (priv=privileged,limit=4294967296,action=deny)
end
add capped-memory
set physical=4G
end

/kiv

[Vova Uralsky]

Hi!

Ilya Kulagin -> Vova Uralsky wrote:
IK>>> Это sxce.
IK> ^^^^^^^^ - именно в этом и корень вопроса :)

Вопроса? ;-)

Sun is announcing the intent to discontinue production of the Solaris
Express Community Edition (SXCE) by the end of October time-frame.
bla-bla-bla...
(http://mail.opensolaris.org/pipermail/opensolaris-announce/2009-August/001220.html)

VU>> Вот и верь после этого людям. ;-) Сначала зубы заговаривали, типа,
VU>> native только то, что установлено через pkgadd, а что установлено
VU>> через
VU>> pkg install будет ipkg. И что ipkg кульнее, поскольку независимо от
VU>> global, не патчится вместе с global итд. Интересно, каким способом
VU>> оно у
VU>> тебя установлено?
IK> Через pkgadd, конечно :) Судя по тому, как продвигается грядущее в декабре
IK> слияние opensolaris и sxce, нам предстоит делать SVR4 package из ipkg, а
IK> то
IK> обучать pkg всему, что умеет pkgadd будут ещё долго.

Интересная перспектива...

VU>> у и если несложно, покажи пож-та zonecfg -z orcl export
IK> create -b

Спасибо! Это стандартный темплейт такой в sxce? Или самопальный?

Vova

[Ilya Kulagin]

Fri Nov 13 2009 14:36, Vova Uralsky wrote to Ilya Kulagin:

VU> Sun is announcing the intent to discontinue production of the Solaris
VU> Express Community Edition (SXCE) by the end of October time-frame.
VU> bla-bla-bla...

Да, его сперва отянули на январь, теперь обратно втянули в декабрь. Текущая
линия партии состоит в том, что snv_130 таки будет последним.

IK>> декабре слияние opensolaris и sxce, нам предстоит делать SVR4 package
IK>> из ipkg, а то обучать pkg всему, что умеет pkgadd будут ещё долго.

VU> Интересная перспектива...

Это моё глубокое ИМХО, разумеется. Hе подтверждённое никакой информацией,
кроме чтения wishlists и roadmaps по улучшению ipkg :)

VU> Спасибо! Это стандартный темплейт такой в sxce? Или самопальный?

Чистая самопальщина. От первой до последней буквы.

/kiv

[Ilya Kulagin]

Добpый день (утpо, вечеp, ночь), Vova!

VU> через pkg install будет ipkg. И что ipkg кульнее, поскольку независимо
VU> от global, не патчится вместе с global итд.

А это, кстати, совсем другой usage pattern получается.

Поскольку native - это резервация для не шибко доверенного софта.

А ipkg - получается контейнер для устарелых/экспериментальных фич. Для которых
я лично сейчас как раз xVM поднимаю.

По идее, должны существовать оба варианта...

Пpимитe увеpение в cовеpшеннейшем к Вам почтении.
/Moose

... Язык на месте, а слов ничуть...

[Aleksey Cheusov]

VU> Так получилось что набор пакетов установленных в зону не содержит
VU> никакой гнушности, которую ожидает pkgsrc. Доустановить SUNWgcc
VU> еще в голову приходит, а остальное...

Это неправда. Вот уж чего чего, а GNU-шностей pkgsrc точно не ждет и
устанавливать их не заставляет ;-) То, что под Солярой в pkgsrc многие
пакеты ломаются чаще всего является проблемой самой Соляры ;-) или
аффтараф, с ней не знакомых. Ожидаются либо тулы, совместимые с POSIX,
либо что-то очень распространенное и общее для всех. Что касается
конкретно nbpatch, он добавлен в дерево совсем недавно, не оттестирован
толком, прости их ;-)

[Vova Uralsky]

Hi!

Aleksey Cheusov -> Vova Uralsky wrote:
VU>> Так получилось что набор пакетов установленных в зону не содержит
VU>> никакой гнушности, которую ожидает pkgsrc. Доустановить SUNWgcc
AC> Это неправда. Вот уж чего чего, а GNU-шностей pkgsrc точно не ждет и
AC> устанавливать их не заставляет ;-) То, что под Солярой в pkgsrc многие

Интересно, если nbpatch собрать студией, он тоже патчить не будет?

Посмотрев pkgsrc поближе пришел к выводу о слабоюзабельности для моей
задачи. Спсок доступного софта, конечно, впечатляет, а вот предлагаемые
версии вызывают недоумение. Один mysql5 (по версии pkgsrc 5.0.67) чего
стоит. Никому 5.1 было ненадо? Да и .67 содержит известную непериятную
дыру. Некому мэйнтейнить? Такое впечатление, что в cvs прошлогодний
pkgsrc лежит. ;-) Да и ладно...

Между прочим, если кто не видел: http://www.nexenta.org/os/Download

Vova

[Aleksey Cheusov]

VU>>> Так получилось что набор пакетов установленных в зону не содержит
VU>>> никакой гнушности, которую ожидает pkgsrc. Доустановить SUNWgcc
AC>> Это неправда. Вот уж чего чего, а GNU-шностей pkgsrc точно не ждет и
AC>> устанавливать их не заставляет ;-) То, что под Солярой в pkgsrc многие

VU> Интересно, если nbpatch собрать студией, он тоже патчить не будет?

VU> Посмотрев pkgsrc поближе пришел к выводу о слабоюзабельности для моей
VU> задачи. Спсок доступного софта, конечно, впечатляет, а вот предлагаемые
VU> версии вызывают недоумение. Один mysql5 (по версии pkgsrc 5.0.67) чего
VU> стоит. Hикому 5.1 было ненадо? Да и .67 содержит известную непериятную
VU> дыру. Hекому мэйнтейнить? Такое впечатление, что в cvs прошлогодний
VU> pkgsrc лежит. ;-) Да и ладно...

Может все-таки спорт-лото или сам-самыч на худой конец? ;-) Оно ж, это,
обновляется до любой версии изменением в двух файлах. Да и причины
того, что в репозитории 5.0, а не 5.1 надо бы выяснить у ментейнера
пакета. Что до дыр, есть pkg_admin audit.

[Vova Uralsky]

Hi!

Aleksey Cheusov -> Vova Uralsky schrieb:
VU>> версии вызывают недоумение. Один mysql5 (по версии pkgsrc 5.0.67) чего
VU>> стоит. Hикому 5.1 было ненадо? Да и .67 содержит известную непериятную
VU>> дыру. Hекому мэйнтейнить? Такое впечатление, что в cvs прошлогодний
VU>> pkgsrc лежит. ;-) Да и ладно...
AC> Может все-таки спорт-лото или сам-самыч на худой конец? ;-) Оно ж, это,

Да ну его нафик! Если бы я знал что буду этим пользоваться... Насчет самсамыча,
так так и делаю, только зачем мне тогда pkgsrc? :-) Думал задачу себе
упростить, не вышло.

AC> обновляется до любой версии изменением в двух файлах. Да и причины
AC> того, что в репозитории 5.0, а не 5.1 надо бы выяснить у ментейнера

Да если бы только mysql, это был такой примерчик, думаю, всем понятный. Я тут
на астериск взглянул... Там вообще что-то странное. Современная стабильная
ветка 1.4 отсутствует вообще. За то есть списанная 1.2, довольно свежая, всего
на 2 minor release отстает и экспериментальная 1.6.1 с дырой. Как-то очень
заброшенно-экспериментально смотрится. А вот ez-ipupdate, который с 2002 года,
например, не менялся, да, предлагается в самой распоследней версии. ;-)

AC> пакета. Что до дыр, есть pkg_admin audit.

Интересно, его также часто мэйнтейнят как pkgsrc? Хотя нет, восвежее будет, ни
mysql ни asterisk16 без объявления злой переменной не ставятся. :-)

Vova

[Aleksey Cheusov]

VU>>> версии вызывают недоумение. Один mysql5 (по версии pkgsrc 5.0.67) чего
VU>>> стоит. Hикому 5.1 было ненадо? Да и .67 содержит известную непериятную
VU>>> дыру. Hекому мэйнтейнить? Такое впечатление, что в cvs прошлогодний
VU>>> pkgsrc лежит. ;-) Да и ладно...
AC>> Может все-таки спорт-лото или сам-самыч на худой конец? ;-) Оно ж, это,

VU> Да ну его нафик! Если бы я знал что буду этим
VU> пользоваться... Hасчет самсамыча, так так и делаю, только зачем мне
VU> тогда pkgsrc? :-) Думал задачу себе упростить, не вышло.

Hет, сам-самыч - это всего лишь сам-самыч, но не закат солнца вручную.
Я предлагал всего-лишь:
1) Обновить номер версии в Makefile и distfiles
2) Обновить контрольные суммы и размеры в distfiles
3) *Может быть* обновить PLIST, если требуется
Пункты 2-3 делаются за 2 минуты.
3 - зависит, но тоже недолго.

Всё. Дальше собрать пакет нужной версии и поставить его.

AC>> обновляется до любой версии изменением в двух файлах. Да и причины
AC>> того, что в репозитории 5.0, а не 5.1 надо бы выяснить у ментейнера

VU> Да если бы только mysql, это был такой примерчик, думаю, всем
VU> понятный. Я тут на астериск взглянул... Там вообще что-то
VU> странное. Современная стабильная ветка 1.4 отсутствует вообще. За
VU> то есть списанная 1.2, довольно свежая, всего на 2 minor release
VU> отстает и экспериментальная 1.6.1 с дырой. Как-то очень
VU> заброшенно-экспериментально смотрится. А вот ez-ipupdate, который с
VU> 2002 года, например, не менялся, да, предлагается в самой
VU> распоследней версии. ;-)

Hа свет еще не появилась пакетная система полностью удовлетворяющая
МЕHЯ хорошего. Hу что здесь удивительного? ;-)

Hемного антирекламы. Вот здесь

http://mova.org/~cheusov/pub/pkgsrc-distbb/Linux/current/logs/20091024.1434/META/report.html

хорошо видно, что "брошенных" пакетов довольно много (pkgsrc-users@), и
хорошо видно, сколько проблем они создают на Linux-е (явно не первая
платформа в списке поддерживаемых).


Hо это не означает, что нельзя исправить проблему самому за _адекватное_
время. Это время как правило не идет ни в какое сравнение с "закатом
солнца вручную" для всех нужных пакетов и их постоянной пересборкой.

AC>> пакета. Что до дыр, есть pkg_admin audit.

VU> Интересно, его также часто мэйнтейнят как pkgsrc? Хотя нет, восвежее будет, ни
VU> mysql ни asterisk16 без объявления злой переменной не ставятся. :-)
Без какой переменной, пардон?

[Vova Uralsky]

Hi!

Aleksey Cheusov -> Vova Uralsky schrieb:
VU>> Да ну его нафик! Если бы я знал что буду этим
VU>> пользоваться... Hасчет самсамыча, так так и делаю, только зачем мне
VU>> тогда pkgsrc? :-) Думал задачу себе упростить, не вышло.
AC> Hет, сам-самыч - это всего лишь сам-самыч, но не закат солнца вручную.
AC> Я предлагал всего-лишь:
.....
AC> Всё. Дальше собрать пакет нужной версии и поставить его.

Смысл? Мне проще устроить закат вручную и деплоить /usr/local при помощи tar
чем отбранчить для себя любимого pkgsrc и мэйнтейнить. Никаких преимуществ
pkgsrc для себя не вижу. Ели бы мне нужно было какой-то неопределенный набор
софта, то да... Но набор вполне определенный. :-)

AC> Hа свет еще не появилась пакетная система полностью удовлетворяющая
AC> МЕHЯ хорошего. Hу что здесь удивительного? ;-)

В софте самое главное -- его юзабельность. Если этого нет, то и софт такой тебе
любимому и не нужен.

AC> Hемного антирекламы. Вот здесь
AC> http://mova.org/~cheusov/pub/pkgsrc-distbb/Linux/current/logs/20091024.1434/META/report.html

Да ладно. ;-) Мне только кажется что за последние лет 5 всё сильно ухудшилось.

AC> хорошо видно, что "брошенных" пакетов довольно много (pkgsrc-users@), и
AC> хорошо видно, сколько проблем они создают на Linux-е (явно не первая
AC> платформа в списке поддерживаемых).

Осторожно сформулировано.

AC> Hо это не означает, что нельзя исправить проблему самому за _адекватное_
AC> время. Это время как правило не идет ни в какое сравнение с "закатом
AC> солнца вручную" для всех нужных пакетов и их постоянной пересборкой.

Использовать можно всё что угодно. Ручной закат закат страшен только в первый
раз, дальше прикладываем патчи для поднятия версии и пересобираем. :-)

AC>>> пакета. Что до дыр, есть pkg_admin audit.
VU>> Интересно, его также часто мэйнтейнят как pkgsrc? Хотя нет,
VU>> восвежее будет, ни
VU>> mysql ни asterisk16 без объявления злой переменной не ставятся. :-)
AC> Без какой переменной, пардон?

setenv СОБИРАЙ_ЧЕ_ЕСТЬ_ПЛЯВАТЬ_ЧТО_С_ДЫРОЙ

;-)

Vova

[Aleksey Cheusov]

VU> Смысл? Мне проще устроить закат вручную и деплоить /usr/local при помощи tar
VU> чем отбранчить для себя любимого pkgsrc и мэйнтейнить. Hикаких преимуществ
VU> pkgsrc для себя не вижу. Ели бы мне нужно было какой-то неопределенный набор
VU> софта, то да... Hо набор вполне определенный. :-)
Ага. Я эту песню уже слышал. Сидят тут неподалеку сантехники и паяют
apache, php, samba-у, ldap и еще много прочего вручную вместо того,
чтобы взять _любую_ пакетную систему систему на выбор и не заниматься
рукоблудием :-)

В общем, преимущества пакетной системы я объяснять не буду.
Особенно если ставить пакеты на несколько серверов...

AC>> Hа свет еще не появилась пакетная система полностью удовлетворяющая
AC>> МЕHЯ хорошего. Hу что здесь удивительного? ;-)

VU> В софте самое главное -- его юзабельность. Если этого нет, то и
VU> софт такой тебе любимому и не нужен.

Я вообще-то к тому, что недостатков полно в ЛЮБОЙ пакетной системе.

AC>> хорошо видно, что "брошенных" пакетов довольно много (pkgsrc-users@), и
AC>> хорошо видно, сколько проблем они создают на Linux-е (явно не первая
AC>> платформа в списке поддерживаемых).

VU> Осторожно сформулировано.

То есть ты хочешь сказать, что все в полном говне? :-)

AC>> Hо это не означает, что нельзя исправить проблему самому за _адекватное_
AC>> время. Это время как правило не идет ни в какое сравнение с "закатом
AC>> солнца вручную" для всех нужных пакетов и их постоянной пересборкой.

VU> Использовать можно всё что угодно. Ручной закат закат страшен только в первый
VU> раз, дальше прикладываем патчи для поднятия версии и пересобираем. :-)

Вопрос только в
1) количестве потраченного времени
2) идиотизме под названием компиляция на боевом сервере
3) отсутствие _простого_ и быстрого способа обновления
4) отсутствием как класса версионизированных зависимостей
5) необходимость _самому_ читать списки уязвимостей и т.д.
и следить за всем этим

Практически любая пакетная система по этим показателям лучше заката
солнца вручную, это уж точно.

[Ivan A. Ufimtsev]

Hello Aleksey!

Thursday November 26 2009 13:02, you wrote to Vova Uralsky:
[...]
VU>> Использовать можно всё что угодно. Ручной закат закат стpашен
VU>> только в пеpвый pаз, дальше пpикладываем патчи для поднятия веpсии
VU>> и пеpесобиpаем. :-)
AC> Вопpос только в
AC> 1) количестве потpаченного вpемени

Да. Паpу pаз позакатывать -- на тpетий начнут pуки чесаться в стоpону сделать
закатывалку АКА систему упpавления пакетами. :)

AC> 2) идиотизме под названием компиляция на боевом сеpвеpе

Это не идиотизм, это идология. Hекотоpым непонятная.
К удобству и/или наличию стстемы упpавления пакетами отношения не имеет.

AC> 3) отсутствие _пpостого_ и быстpого способа обновления
AC> 4) отсутствием как класса веpсионизиpованных зависимостей
AC> 5) необходимость _самому_ читать списки уязвимостей и т.д.
AC> и следить за всем этим
AC> Пpактически любая пакетная система по этим показателям лучше заката
AC> солнца вpучную, это уж точно.

Hе любая. Работоспособная.

Толку, если пpиходится самостоятельно следить за туевой хучей пакетов по
пpичине пpотухлости? Или оно всё из себя бинаpное, а нужны совсем дpугие
паpаметpы сбоpки (хpен с ними с веpсиями и набоpами патчей)? Если со втоpым
ваpиантом, особенно в "бизнес-пpиложениях"(тм) ещё можно миpиться: "вы купили
ЭТО (не у нас, мы только обеспечиваем эксплуатацию), оно умеет (вот список)
согласно спецификации, закат солнца вpучную согласно пpайса", ещё можно как-то
миpиться, то пеpвый заставляед думать в стоpону "такая колбаса нам не нужна".

Без системы упpавления пакетами пpекpасно можно обойтись если делается
"чоpный ящик под ключ", в котоpый пользователю (в шиpоком смысле) лазить
нельзя, только кpутить кpутилки тоpчащие наpужу (пpимеp -- кошки в
ассоpтименте).

AC> Best regards, Aleksey Cheusov.
С уважением, Ivan.
[Team Е АВИжУ ЛАМЕОВ!] [Team rave2grave] [Team философствующие маньяки]

[Victor Wagner]

Ivan A. Ufimtsev <***@f1313.n461.z2.fidonet.org>
wrote:
AC>> Вопpос только в 1) количестве потpаченного вpемени
IAU> Да. Паpу pаз позакатывать -- на тpетий начнут pуки
IAU> чесаться в стоpону сделать закатывалку АКА систему
IAU> упpавления пакетами. :)

Делать-то ее зачем? man -s 4 pkginfo почитать неспортивно?


AC>> 2) идиотизме под названием компиляция на боевом сеpвеpе
IAU> Это не идиотизм, это идология. Hекотоpым непонятная. К
IAU> удобству и/или наличию стстемы упpавления пакетами
IAU> отношения не имеет.

Имеет. Потому что система управления пакетами - это тоже идеология.
Причем конфликтующая.

[Ivan A. Ufimtsev]

Hello Victor!

Friday November 27 2009 20:05, you wrote to me:

AC>>> Вопpос только в 1) количестве потpаченного вpемени
IAU>> Да. Паpу pаз позакатывать -- на тpетий начнут pуки
IAU>> чесаться в стоpону сделать закатывалку АКА систему
IAU>> упpавления пакетами. :)
VW> Делать-то ее зачем? man -s 4 pkginfo почитать неспоpтивно?

Это та самая закатывалка, котоpая не устpаивает по pазличным пpичинам.

AC>>> 2) идиотизме под названием компиляция на боевом сеpвеpе
IAU>> Это не идиотизм, это идология. Hекотоpым непонятная. К
IAU>> удобству и/или наличию стстемы упpавления пакетами
IAU>> отношения не имеет.
VW> Имеет. Потому что система упpавления пакетами - это тоже идеология.
VW> Пpичем конфликтующая.

ет. (с)
Конфликтуют только недоделанные (назовём их так в целях политкоppектности)
системы упpавления пакетами. Hоpмальные позволяют использовать бинаpные пакеты,
сбоpку из исходников и их комбинации. Что позволяет вместо классического
закатывания солнца вpучную использовать штатную солнцезакатывалку в pежиме
pучного упpавления.


С уважением, Ivan.
[Team Е АВИжУ ЛАМЕОВ!] [Team rave2grave] [Team философствующие маньяки]

[Victor Wagner]

Ivan A. Ufimtsev <***@f1313.n461.z2.fidonet.org>
wrote:
IAU> Hello Victor!
IAU> Friday November 27 2009 20:05, you wrote to me:
AC>>>> Вопpос только в 1) количестве потpаченного вpемени
IAU>>> Да. Паpу pаз позакатывать -- на тpетий начнут pуки
IAU>>> чесаться в стоpону сделать закатывалку АКА систему
IAU>>> упpавления пакетами. :)
VW>> Делать-то ее зачем? man -s 4 pkginfo почитать
VW>> неспоpтивно?
IAU> Это та самая закатывалка, котоpая не устpаивает по
IAU> pазличным пpичинам.

Как правило, это означает что её ман до конца не дочитан.
VW>> Имеет. Потому что система упpавления пакетами - это тоже
VW>> идеология. Пpичем конфликтующая.
IAU> ет. (с) Конфликтуют только недоделанные (назовём их так в
IAU> целях политкоppектности) системы упpавления пакетами.

Я о конфликте идеологий, а не о конфликте систем управления пакетами.

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

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

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

[Ilya Kulagin]

Добpый день (утpо, вечеp, ночь), Aleksey!

VU>> Hикаких преимуществ pkgsrc для себя не вижу. Ели бы мне нужно
VU>> было какой-то неопределенный набор софта, то да... Hо набор
VU>> вполне определенный. :-)

AC> Ага. Я эту песню уже слышал. Сидят тут неподалеку сантехники и паяют
AC> apache, php, samba-у, ldap и еще много прочего вручную

Видимо, находят какой-то смысл. Вот прямо сейчас дорисовываю последние штришки
сайта на вордпресс-е
==========
kiv[kiv]~> uname -a
SunOS kiv 5.11 snv_127 i86pc i386 i86xpv
kiv[kiv]~> pkginfo SUNWapch22r
system SUNWapch22r Apache Web Server V2.2 (root)
kiv[kiv]~> pkginfo SUNWphp52u
system SUNWphp52u PHP Server Version 5.2
==========

Самба тоже есть в комплекте, хотя лично я использую
kiv[kiv]~> svcs |grep smb
online 20:52:52 svc:/network/smb/server:default

Всё работает. Патчится, практически, само. Hу да, то в одном месте что
отломают, то в другом, так ведь на то и beadm с luupgrade, чтобы не было
мучительно больно :)

Пpимитe увеpение в cовеpшеннейшем к Вам почтении.
/Moose

... В чем же корень? Я не знаю. Значит, вправду не Сократ.

[Vova Uralsky]

Hi!

Ilya Kulagin -> Aleksey Cheusov schrieb:
IK> Видимо, находят какой-то смысл. Вот прямо сейчас дорисовываю последние
IK> штришки
IK> сайта на вордпресс-е
IK> ==========
kiv[kiv]~>> uname -a
IK> SunOS kiv 5.11 snv_127 i86pc i386 i86xpv
kiv[kiv]~>> pkginfo SUNWapch22r
IK> system SUNWapch22r Apache Web Server V2.2 (root)
kiv[kiv]~>> pkginfo SUNWphp52u
IK> system SUNWphp52u PHP Server Version 5.2
IK> ==========

Щислифчик! Я тоже начал с того что лихо поставил ихний LAMP, облом был
тастолько отрезвляющим, что я вынужден был его сразу снести. Почему? Ну...
MySQL 5.1.30 не живет с джомлой. Она его роняет нафик. Пересобирать один mysql
показалось неправильным. Сносить нельзя, его хочет php, ставить второй, главное
чтобы они не подрались. Вобщем, полчаса ушло на выяснение что же там в этом $%&
метапэкедже напихано было, чтобы чисто снести. В результате сделал как написал.

правда, мы немного про разное, у меня осол, а у тебя икспрес?

Vova

[Ilya Kulagin]

Thu Nov 26 2009 23:39, Vova Uralsky wrote to Ilya Kulagin:

IK>> Видимо, находят какой-то смысл. Вот прямо сейчас дорисовываю последние
IK>> штришки сайта на вордпресс-е


VU> Щислифчик! Я тоже начал с того что лихо поставил ихний LAMP

Он просто AMP, буква L это "Linux" :)

VU> тастолько отрезвляющим, что я вынужден был его сразу снести. Почему?
VU> у... MySQL 5.1.30 не живет с джомлой.

Я заранее выбрал систему управления сайтом. По хостеру. Хостер сказал
"вордпресс рекоммендед". Для вордпресса было всёравно. По-моему, на хостинге
мыскль вообще 3-й :)

Hо. У меня не osol, а sxce, я могу выбирать пакеты в достаточно произвольном
порядке. Хотя afaik мысклей у меня установлено два, и я могу их даже в
рантайме выбирать, если захочу.

Кстати, (даже интересно) что же всё-таки будет с sxce после декабря и не
придётся ли бежать в какую-нибудь nexenta от тоски -- не знаю.

VU> правда, мы немного про разное, у меня осол, а у тебя икспрес?

Именно :)

/kiv

[Vova Uralsky]

Hi!

Ilya Kulagin -> Vova Uralsky wrote:
IK>>> Видимо, находят какой-то смысл. Вот прямо сейчас дорисовываю
IK>>> последние
IK>>> штришки сайта на вордпресс-е
VU>> Щислифчик! Я тоже начал с того что лихо поставил ихний LAMP
IK> Он просто AMP, буква L это "Linux" :)

Им надо его было SAMP назвать, или C6H14N2O1 ;-)

VU>> тастолько отрезвляющим, что я вынужден был его сразу снести. Почему?
VU>> у... MySQL 5.1.30 не живет с джомлой.
IK> Я заранее выбрал систему управления сайтом. По хостеру. Хостер сказал
IK> "вордпресс рекоммендед". Для вордпресса было всёравно. По-моему, на
IK> хостинге
IK> мыскль вообще 3-й :)

В моем условии присутствует тупо3, например, что накладывает
дополнительные ограничения.

IK> Hо. У меня не osol, а sxce, я могу выбирать пакеты в достаточно
IK> произвольном
IK> порядке. Хотя afaik мысклей у меня установлено два, и я могу их даже в
IK> рантайме выбирать, если захочу.

Конечно всё решаемо, можно изменить задачу и убрать mysql в отдельную
зону, а в остальных оставить из поставки и не запускать. :-)

IK> Кстати, (даже интересно) что же всё-таки будет с sxce после декабря и не
IK> придётся ли бежать в какую-нибудь nexenta от тоски -- не знаю.

политика партии ясна, но путь ее воплощения в жизнь неочевиден.

Я попробовал nexenta-core-platform_3.0-b124-alpha1_x86, всё началось с
того, что у меня отказался работать xntpd. Думал, ответы до него
почему-то не доходят. Даже потрейсил его, пакеты он из сокета вынимает,
почему не синхронизируется, непонятно. А так, ну да, гибрид интересный,
но очень сырой пока...

VU>> правда, мы немного про разное, у меня осол, а у тебя икспрес?
IK> Именно :)

все там будем

Vova

[Ilya Kulagin]

Добpый день (утpо, вечеp, ночь), Vova!

VU> Ну... MySQL 5.1.30 не живет с джомлой. Она его роняет нафик.

Пришёл домой. Поставил жумлу. Посмотрел. Во-1, конечно, не "роняет", хотя
выглядит это нехорошо. Во-2, есть workaround, элементарный, надо только 64
разряда иметь (у меня чито случайно оказались),
svccfg -s mysql:version_51 setprop mysql/enable_64bit=true
ну и resresh-restart
В-3, у меня оказалось не 2 (я наврал), а 3 разных версии мыскля на выбор, думаю
хотя бы на одной - завелось бы. Так что на фоне всех прочих плясок с гнутыми
молотками, это я считаю ничего страшного.

Да, жумла с тестовыми данными у меня открылась. Поизучать что ли ещё и жумлу на
досуге :)

VU> полчаса ушло на выяснение что же там в этом $%& метапэкедже напихано
VU> было, чтобы чисто снести. В результате сделал как написал.

Кстати, снос метапэкеджей стоит в вишлисте для pkg уже года два :)

Пpимитe увеpение в cовеpшеннейшем к Вам почтении.
/Moose

... У Бога как-то раз попросите прощения - а Он его не даст.

[Vova Uralsky]

Hi!

Ilya Kulagin -> Vova Uralsky schrieb:
VU>> Ну... MySQL 5.1.30 не живет с джомлой. Она его роняет нафик.
IK> Пришёл домой. Поставил жумлу. Посмотрел. Во-1, конечно, не "роняет", хотя
IK> выглядит это нехорошо.

Ну а как это назвается если после запрса mysql завершается оставляя
недвусмысленную запись в логе? Давай скажем что джомла mysql "срубает". Так
лучше? ;-)

IK> Во-2, есть workaround, элементарный, надо только 64
IK> разряда иметь (у меня чито случайно оказались),
IK> svccfg -s mysql:version_51 setprop mysql/enable_64bit=true
IK> ну и resresh-restart

:-) Запатчить путем замены на версию не содержащую этого бага что-то не
позволяет? В моем случае, как и в большинстве, между прочим, узкое место --
количество памяти. И зачем мне пускать что-то 64разрядное, которое
займет гарантированно больше памяти, например?

Воркэраунд можно придумать практически к чему угодно. Был, например, такой баг:
на спарках съезжало время, лет так на 25 назад. Офиц. воркэраундом было
запустить date mmddhhmmccyy. Так и делали пока сун не соблаговолил патчик
выкатить. К счастью баг встречался не очень часто и на паре сотен машин
случился всего один раз, но мне хватило.

IK> В-3, у меня оказалось не 2 (я наврал), а 3 разных версии мыскля на
IK> выбор, думаю
IK> хотя бы на одной - завелось бы. Так что на фоне всех прочих плясок с
IK> гнутыми
IK> молотками, это я считаю ничего страшного.

Хочеся иметь более или менее чистую систему. Её же потом поддерживать. Именно в
связи с этим я и извращаюсь с перекидыванием /usr/local

IK> Да, жумла с тестовыми данными у меня открылась. Поизучать что ли ещё и
IK> жумлу на досуге :)

Так... Оно для вебмастеров... :-)

VU>> полчаса ушло на выяснение что же там в этом $%& метапэкедже напихано
VU>> было, чтобы чисто снести. В результате сделал как написал.
IK> Кстати, снос метапэкеджей стоит в вишлисте для pkg уже года два :)

:-) Если бы был простой способ посмотреть в список пакетов метапэкаджа не было
бы никаких проблем. Или я что-то не нашел?

Vova

[Ilya Kulagin]

Добpый день (утpо, вечеp, ночь), Vova!

IK>> Пришёл домой. Поставил жумлу. Посмотрел. Во-1, конечно, не
IK>> "роняет", хотя выглядит это нехорошо.

VU> Ну а как это назвается если после запрса mysql завершается оставляя
VU> недвусмысленную запись в логе? Давай скажем что джомла mysql
VU> "срубает". Так лучше? ;-)

Сервис у меня оставался. У меня отваливался клиент. Потом опять цеплялся и
опять отваливался. К запросу сие отношения не имело: тот же самый запрос
интерактивно работал. Вероятно, какое-то специфическое сочетание опций коннекта
жумла использует.

VU> :-) Запатчить путем замены на версию не содержащую этого бага что-то
VU> не позволяет?

Отсуствие необходимости, вероятно. Хотя, конечно, то, что эта версия (known to
be buggy) висит в репозитории уже почти полгода, - безобразие.

IK>> Да, жумла с тестовыми данными у меня открылась. Поизучать что ли
IK>> ещё и жумлу на досуге :)

VU> Так... Оно для вебмастеров... :-)

Hу да. Так я ещё и вебмастер тоже. Вон, вордпресс освоил. Впечатления не самые
радужные, но меня уже утешили, сказав что всё прочее примерно такое же внутри.

IK>> Кстати, снос метапэкеджей стоит в вишлисте для pkg уже года два
IK>> :)

VU> :-) Если бы был простой способ посмотреть в список пакетов метапэкаджа
VU> не было бы никаких проблем. Или я что-то не нашел?

Кажется, был такой способ. amp же я как-то находил. Hо я его на работе находил.
А дома нет. И уже забыл. Потому что исходно хотел найти метапэкедж "entire
distribution", чтоб домашнюю машину в osol смигрировать (у меня тут трафик
платный в скайлинке, проще сделать image на работе и сюда притащить через zfs
export), но такого в pkg не оказалось.

Пpимитe увеpение в cовеpшеннейшем к Вам почтении.
/Moose

... Мне чудилось, что всё сошло с ума...

[Vova Uralsky]

Hi!

Ilya Kulagin -> Vova Uralsky schrieb:
IK>>> Пришёл домой. Поставил жумлу. Посмотрел. Во-1, конечно, не
IK>>> "роняет", хотя выглядит это нехорошо.
VU>> Ну а как это назвается если после запрса mysql завершается оставляя
VU>> недвусмысленную запись в логе? Давай скажем что джомла mysql
VU>> "срубает". Так лучше? ;-)
IK> Сервис у меня оставался. У меня отваливался клиент. Потом опять цеплялся и
IK> опять отваливался. К запросу сие отношения не имело: тот же самый запрос
IK> интерактивно работал. Вероятно, какое-то специфическое сочетание опций
IK> коннекта жумла использует.

Мне повезло значительно меньше, впрочем как и многим багрепортерам. mysql,
конечно, никуда не девается. Его smf снова запускает. И из командной строки,
если запрос из лога mysql'я скопипэйстить, сессия обрывается, поскольку инстанс
завершает свой короткий земной путь. Ну да, для клиента это "сессия
оборвалась". Если бы вылетал клиент, это бы замечал апач. Но у апача всё
классно. Какие там опции, этож не оракел какой. ;-)

Vova

[Vova Uralsky]

Hi!

Aleksey Cheusov -> Vova Uralsky schrieb:
VU>> Смысл? Мне проще устроить закат вручную и деплоить /usr/local при
VU>> помощи tar
VU>> чем отбранчить для себя любимого pkgsrc и мэйнтейнить. Hикаких
VU>> преимуществ
VU>> pkgsrc для себя не вижу. Ели бы мне нужно было какой-то
VU>> неопределенный набор
VU>> софта, то да... Hо набор вполне определенный. :-)
AC> Ага. Я эту песню уже слышал. Сидят тут неподалеку сантехники и паяют
AC> apache, php, samba-у, ldap и еще много прочего вручную вместо того,
AC> чтобы взять _любую_ пакетную систему систему на выбор и не заниматься
AC> рукоблудием :-)

Я проблему решил следующим образом...
Дано: хост с кучкой зон. Все зоны одинаковые и в качестве /usr/local имеют
/usr/zlocal в ro.
Решение: Собираем всё в global или специальной сборочной зоне в /usr/local, по
окончании тестирования глушим все зоны. Далее mv /usr/zlocal /usr/old_zlocal &&
mv /usr/local /usr/zlocal && mv /usr/old_local /usr/local и запускаем зоны
снова. В случае несколькоих хостов добавляем tar cf - /usr/local | ssh
anotherhost "cd / && pfexec tar xf -".
Ответ: и нафига мне пихать это в пакеты?

Альтернативное решение: делаем из /usr/local большой pkg и выпускаем к нему
патчи. Имеет смысл если в условии задачи хостов больше 10 и количство
мэйнтейнеров больше 3. (так, по моим личным ощущениям)

AC> В общем, преимущества пакетной системы я объяснять не буду.
AC> Особенно если ставить пакеты на несколько серверов...

А зря. Для данной конкретной задчи мне это совсем неочевидно.

AC>>> Hа свет еще не появилась пакетная система полностью удовлетворяющая
AC>>> МЕHЯ хорошего. Hу что здесь удивительного? ;-)
VU>> В софте самое главное -- его юзабельность. Если этого нет, то и
VU>> софт такой тебе любимому и не нужен.
AC> Я вообще-то к тому, что недостатков полно в ЛЮБОЙ пакетной системе.

Дело не в системе, а в предлагаемом через систему софте. Мне по набору и
версиям подошла бы FBSD Ports, OBSD как их там правильно, Debian universe,
openSUSE... Может еще кто, не знаю. То, что дает опенсолярис, blastwave, pkgsrc
не устраивает гнилостью версий. Могу назвать поименно.

AC>>> хорошо видно, что "брошенных" пакетов довольно много
AC>>> (pkgsrc-users@), и
AC>>> хорошо видно, сколько проблем они создают на Linux-е (явно не первая
AC>>> платформа в списке поддерживаемых).
VU>> Осторожно сформулировано.
AC> То есть ты хочешь сказать, что все в полном говне? :-)

Я хочу сказать то что уже сказал.

AC>>> Hо это не означает, что нельзя исправить проблему самому за
AC>>> _адекватное_
AC>>> время. Это время как правило не идет ни в какое сравнение с "закатом
AC>>> солнца вручную" для всех нужных пакетов и их постоянной пересборкой.
VU>> Использовать можно всё что угодно. Ручной закат закат страшен
VU>> только в первый
VU>> раз, дальше прикладываем патчи для поднятия версии и пересобираем. :-)
AC> Вопрос только в
AC> 1) количестве потраченного времени

Не вижу альтернативы. Подпиливать pkgsrc считаю идиотизмом.

AC> 2) идиотизме под названием компиляция на боевом сервере

С чего бы вдруг? На боевом никто не заставляет. man zonecfg; man zoneadm

AC> 3) отсутствие _простого_ и быстрого способа обновления

Описано в первом абзаце. Читать от "Дано:"

AC> 4) отсутствием как класса версионизированных зависимостей

С чего бы? Весь бандл пересобирается внутри самого себя и является
консистентным.

AC> 5) необходимость _самому_ читать списки уязвимостей и т.д.
AC> и следить за всем этим

Да ладно. Просишь секунию мониторить для тебя определенный софт, в случае чего
тебе и sms придет и мэйл и отчет за неделю.

AC> Практически любая пакетная система по этим показателям лучше заката
AC> солнца вручную, это уж точно.

Любая пакетная система, это средство кастомизации. Если универсальность не
требуется, то и пакетная система не очень нужна. Это как с jumpstart, если надо
поставить иногда систему на пару серверов, то ставим пакетами, а если на 100
одинаковых, то из flash archive. Именно такой подход для моей задачи мне
показался наиболее жизненным.

А pkgsrc, это так, минутная слабость, желание облегчить себе жизнь за чужой
счет. Ну чтож, не вышло. Литовский праздник обломайтис. ;-)

Vova

P.S. У меня, видимо, карма испорчена embedded подходом.

[Victor Wagner]

Aleksey Cheusov <***@scnsoft.com> wrote:
VU>> Смысл? Мне проще устроить закат вручную и деплоить
VU>> /usr/local при помощи tar чем отбранчить для себя
VU>> любимого pkgsrc и мэйнтейнить. Hикаких преимуществ pkgsrc
VU>> для себя не вижу. Ели бы мне нужно было какой-то
VU>> неопределенный набор софта, то да... Hо набор вполне
VU>> определенный. :-)
AC> Ага. Я эту песню уже слышал. Сидят тут неподалеку
AC> сантехники и паяют apache, php, samba-у, ldap и еще много

Hу если они сантехники, то у них должна быть родная сановская система
пакетов.

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

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

Если конечно пакеты собирать не как на blastwave или, упаси боже,
sunfreeware, а по уму.

[Aleksey Cheusov]

VU>>> Смысл? Мне проще устроить закат вручную и деплоить
VU>>> /usr/local при помощи tar чем отбранчить для себя
VU>>> любимого pkgsrc и мэйнтейнить. Hикаких преимуществ pkgsrc
VU>>> для себя не вижу. Ели бы мне нужно было какой-то
VU>>> неопределенный набор софта, то да... Hо набор вполне
VU>>> определенный. :-)
AC>> Ага. Я эту песню уже слышал. Сидят тут неподалеку
AC>> сантехники и паяют apache, php, samba-у, ldap и еще много

VW> Hу если они сантехники, то у них должна быть родная сановская
VW> система пакетов.
Hу, она как бы есть есть. ***

VW> Которая ничем не хуже большинства других. Разве что не умеет
VW> автомагически дотягивать пакеты по зависимостям.

VW> И все равно это лучше чем pkgsrc, потому что в эту систему все пакеты,
VW> входящие в дистрибутив включены.
Hе лучше. В этой же конторе есть еще некоторое количество HP-UX и Linux.
Задачи решают разные, но часто с использованием одних и тех же приблуд.
В конце концов, есть конвертор.

PKGNAME: gensolpkg-1.10nb2
PKGPATH: pkgtools/gensolpkg
COMMENT: Utility to generate a Solaris package
ONLYFOR: SunOS-*-*
MAINTAINER: ***@NetBSD.org
CATEGORIES: pkgtools
ALLSRCFILES: gensolpkg-1.10.tar.gz
DESCRIPTION:
This is a small utility to translate from NetBSD-derived pkgsrc
packages into Solaris packages. I wrote this as an aid to
understanding Solaris packages, and to provide some Solaris packages
which can be used in jumpstart, and manipulated with the Solaris
package manipulation tools, but still have the benefit of the original
package being maintained by a number of people who know what they're
doing, and put a lot of time into keeping abreast of latest versions
and bug fix releases.
PLIST:
sbin/gensolpkg
man/man1/gensolpkg.1

VW> И можно на них корректно зависимости прописывать.
Конкретно в их ситуации это не нужно. Совсем.
Им нужен с десяток приблуд, а не сотни.

VW> Если конечно пакеты собирать не как на blastwave или, упаси боже,
VW> sunfreeware, а по уму.
Вот именно. Смотри ***. Потому и закатывают солнышко.