🚀 go-pugleaf

Toper wrote on 2009-04-24 13:31:

> taki przykład:

Wpadłeś na:

> $ portupgrade subversion

> No to ok, chcę przeinstalować `devel/apr-svn'
> 
> # make install
[ciach]
> # pkg_delete apr-1.3.3.1.3.4

A na portupgrade apr już nie? ;-)

> No to powiedzcie, jaka jest właściwa, słuszna droga postępowania w takim
> przypadku? Dlaczego we FreeBSD nie można po prostu zrobić yum update...
> ja lubię to FreeBSD, ale ten update to mnie zawsze dobija :(

portupgrade -irRvb? ;-)

-- 
*   Maciej Wierzbicki * At paranoia's poison door  *
*   VOO1-RIPE   *

Maciej Wierzbicki pisze:
> 
> A na portupgrade apr już nie? ;-)
no pewnie że tak! tylko co z tego, jak dostaję, że ok:
# portupgrade apr

więc znowu robię:
# portupgrade subversion

i dostaję:
===>  Configuring for subversion-1.5.4_2

You should build `devel/apr-svn' with db4 support to use subversion with it.
Please rebuild `devel/apr-svn' with option
`APR_UTIL_WITH_BERKELEY_DB=yes' and try again.

Or you can disable db4 support. Only 'fs' repository backend will be
available.
To disable db4 support, define WITHOUT_BDB.

*** Error code 1

Stop in /usr/ports/devel/subversion.
*** Error code 1

Stop in /usr/ports/devel/subversion.
** Command failed [exit code 1]: /usr/bin/script -qa
/tmp/portupgrade.18457.0 env UPGRADE_TOOL=portupgrade
UPGRADE_PORT=subversion-1.4.4_1 UPGRADE_PORT_VER=1.4.4_1 make
** Fix the problem and try again.
** Listing the failed packages (-:ignored / *:skipped / !:failed)
        ! devel/subversion (subversion-1.4.4_1) (unknown build error)

czyli jestem w tym samym punkcie.

> 
>> No to powiedzcie, jaka jest właściwa, słuszna droga postępowania w takim
>> przypadku? Dlaczego we FreeBSD nie można po prostu zrobić yum update...
>> ja lubię to FreeBSD, ale ten update to mnie zawsze dobija :(
> 
> portupgrade -irRvb? ;-)
> 

mogę, ale z racji tego, że jakoś problemy mam z tymi updatami to wolę je
robić pojedynczo, a z kolei robienie pojedynczo kończy się j.w. :(

Pozdrawiam
Toper

Maciej Wierzbicki pisze:
> 
> portupgrade -irRvb? ;-)
> 
Spróbowałem:


===>  Configuring for subversion-1.5.4_2

You should build `devel/apr-svn' with db4 support to use subversion with it.
Please rebuild `devel/apr-svn' with option
`APR_UTIL_WITH_BERKELEY_DB=yes' and try again.

Or you can disable db4 support. Only 'fs' repository backend will be
available.
To disable db4 support, define WITHOUT_BDB.

*** Error code 1

Stop in /usr/ports/devel/subversion.
*** Error code 1

Stop in /usr/ports/devel/subversion.
** Command failed [exit code 1]: /usr/bin/script -qa
/tmp/portupgrade.20699.0 env UPGRADE_TOOL=portupgrade
UPGRADE_PORT=subversion-1.4.4_1 UPGRADE_PORT_VER=1.4.4_1 make
** Fix the problem and try again.
--->  Build of devel/subversion ended at: Fri, 24 Apr 2009 16:20:19
+0200 (consumed 00:00:11)
--->  Upgrade of devel/subversion ended at: Fri, 24 Apr 2009 16:20:19
+0200 (consumed 00:00:58)
--->  ** Upgrade tasks 1: 0 done, 0 ignored, 0 skipped and 1 failed
--->  Listing the results (+:done / -:ignored / *:skipped / !:failed)
        ! devel/subversion (subversion-1.4.4_1) (unknown build error)
--->  Packages processed: 0 done, 0 ignored, 0 skipped and 1 failed
--->  Session ended at: Fri, 24 Apr 2009 16:20:19 +0200 (consumed 00:01:15)

at Fri 24 of Apr 2009 13:31, Toper wrote:

> taki przykład:
[...]

nieważne
[...]

> a mod_security nie chcą odinstalowywać, bo to pociąga za sobą następne
> pakiety ;-) i tak w kółko.
> 
> No to powiedzcie, jaka jest właściwa, słuszna droga postępowania w
> takim przypadku? Dlaczego we FreeBSD nie można po prostu zrobić yum
> update... ja lubię to FreeBSD, ale ten update to mnie zawsze dobija :(

Takie coś stało się regułą od jakichś dwóch lat. Teraz to dziwię się,
jeśli jakiś update pójdzie bez komplikacji, od pierwszego strzału.

A jaka słuszna droga postępowania? Poczekać parę godzin, dni, 
albo tygodni, aż maintainer *) doprowadzi do takiego stanu,
że 'portupgrade paczka' wystarczy. Dotyczy to takich sytuacji
jak moja, kiedy maszyna nieprodukcyjna, służy jako desktop
do wszystkiego, kiedy w nadziei, że w końcu poprawią lub
dodadzą coś brakującego, od razu kompiluje się każdą nowość.

Czasem trzeba samemu coś pogrzebać w portach. Np kiedy ostatnio
poprawili X-y i driver nvidia przestał działać jak powinien,
trzeba było samemu poprawić na nowszą wersję, a która została
włączona do systemu portów dopiero po dwóch tygodniach.

W tym czasie kiedy weszło 7.0 debian wypuścił produkcyjnego 'lenny'
i rozwojowego 'etch'. Bawiłem się tym drugim i przez rok nie było
żadnych problemów, wystarczyła jedna małpia sekwencja w aptitude,
aby w kwestii portów/paczek zrobić wszystko co się chciało.
Ten rok debiana to tak jak rok wersji 7.0 dla FreeBSD i kompilowania
wszystkich poprawek i nowości (w debianie dodatkowo Gnome, z którego
zrezygnowałem pod FreeBSD).
Nawet nie można porównać z awaryjnością FreeBSD, bo zero w mianowniku.

Sam system update-ów to nie wszystko i on sam nie wystarczy 
aby zdecydować się na trwałą zmianę systemu. Warto się przyjrzeć
co takiego jest w debianie, że takich problemów nie ma.



*) ostatnie kuriozum to taki wpis/usr/ports/UPDATING: 
    2) Reinstall everything that depends on Perl:
        portupgrade -fr perl
co się może przełożyć na tysiące pakietów z KDE3 i 4, OpenOffice
i podobnymi kobyłami włącznie (tak było u mnie). Jeśli ktoś nie wie, 
że perl-after-upgrade sprawdza, które paczki _NAPRAWDĘ_ wymagają
przekompilowania może się załamać (u mnie wyszło, że _ŻADNA_ paczka),
albo co gorsza kompilować ;-)


-- 
Bodek

Toper wrote:

> mogę, ale z racji tego, że jakoś problemy mam z tymi updatami to wolę je
> robić pojedynczo, a z kolei robienie pojedynczo kończy się j.w. :(

Pojedynczo? A po co pojedynczo? Lepiej odrazu wszystkie. Ja robie tak:

# portversion -c > a.sh

# sh a.sh -F

i jak się wszystkie potrzebne żrodełka prawidłowo ściagną daję:

# sh a.sh

To ma taką zaletę, że wszystkie pakiety ustawiają się w odpowiedniej
kolejce - zgodnie z zależnosciami i nie widzę powodu, by dla kazdego pakietu
z osobna uruchamiać portupgrade.

Rzadko zdażają mi się problemy z aktualizacją.
Jedyny problem jest przy pakietach KDE4, bo się upiera, że musi kompilować
boost_python, choć mam skompilowanego boosta z opcją WITH_PYTON, czy jakoś
tak. Próbowałem wykluczać boosta opcją -x z różnymi kombinacjami*), ale nie
działa. Ale to nie problem, bo dla pakietów kde4 dodaję opcję -k, a kiedy
zaczyna kompilować boosta przerywam ^C i "idzie" dalej bez problemu.

Jak już pisałem rzadko mi się zdażają problemy z aktualizacjami, ale
przyznaję, że ostatnimi czasy coś się we FreeBSD popsuło. ;(

*)-x boost\*, -x boost_python, -x devel/boost i kilka innych, jakie mi do
głowy przyszły; próbowałem dawac jako pierwszą i ostatnią opcję w poleceniu
i nic...

-- 
Piotr Sietnik
s i e t p [@] p o c z t a [na] . o n e t . p l

Bodek wrote:

> *) ostatnie kuriozum to taki wpis/usr/ports/UPDATING:
>     2) Reinstall everything that depends on Perl:
>         portupgrade -fr perl
> co się może przełożyć na tysiące pakietów z KDE3 i 4, OpenOffice
> i podobnymi kobyłami włącznie (tak było u mnie). Jeśli ktoś nie wie,
> że perl-after-upgrade sprawdza, które paczki _NAPRAWDĘ_ wymagają
> przekompilowania może się załamać (u mnie wyszło, że _ŻADNA_ paczka),
> albo co gorsza kompilować ;-)

Perla powinni już dawno wrzucić do basesystemu, bo jest tak samo potrzebny
w systemie jak gcc, cut, grep czy awk.

-- 
Piotr Sietnik
s i e t p [@] p o c z t a [na] . o n e t . p l

at Sun 26 of Apr 2009 01:31, PetruS wrote:

> Toper wrote:
> 
>> mogę, ale z racji tego, że jakoś problemy mam z tymi updatami to wolę
>> je robić pojedynczo, a z kolei robienie pojedynczo kończy się j.w. :(
> 
> Pojedynczo? A po co pojedynczo? Lepiej odrazu wszystkie. Ja robie tak:
> 
> # portversion -c > a.sh
> 
> # sh a.sh -F
> 
> i jak się wszystkie potrzebne żrodełka prawidłowo ściagną daję:
> 
> # sh a.sh
> 
> To ma taką zaletę, że wszystkie pakiety ustawiają się w odpowiedniej
> kolejce - zgodnie z zależnosciami i nie widzę powodu, by dla kazdego
> pakietu z osobna uruchamiać portupgrade.

Jak masz 'portupgrade a b c d ...' albo 'portupgrade -a'
pewnie też się ustawiają, bo na pewno nie są kompilowane
w kolejności wpisania czy w kolejności alfabetycznej.

 
> Rzadko zdażają mi się problemy z aktualizacją.

1 Komputer desktop do wszystkiego, 1000 paczek, update
prawie zawsze po włączeniu  - 90% aktualizacji to problemy.

2 Skromny serwer www i poczty, 200 paczek, update od wielkiego
dzwonu - parę procent to problemy.


> Jedyny problem jest przy pakietach KDE4, bo się upiera, że musi
> kompilować boost_python, choć mam skompilowanego boosta z opcją
> WITH_PYTON, czy jakoś tak. Próbowałem wykluczać boosta opcją -x z
> różnymi kombinacjami*), ale nie działa. Ale to nie problem, bo dla
> pakietów kde4 dodaję opcję -k, a kiedy zaczyna kompilować boosta
> przerywam ^C i "idzie" dalej bez problemu.

Z KDE3 i KDE4 jednocześnie - żadnych problemów. I to jest dziwne,
bo kobyła wielka i jak na nieskore do nowości FreeBSD dosyć
szybko przygotowane do standardowej instalacji (debian, zazwyczaj
szybszy w nowościach, potrafi wypuścić tę samą wersję parę
miesięcy później)

> Jak już pisałem rzadko mi się zdażają problemy z aktualizacjami, ale

dar/darzyć/zdarzenie - inaczej nie da rady zapamiętać :-)


> przyznaję, że ostatnimi czasy coś się we FreeBSD popsuło. ;(
> 
> *)-x boost\*, -x boost_python, -x devel/boost i kilka innych, jakie mi
> do głowy przyszły; próbowałem dawac jako pierwszą i ostatnią opcję w
> poleceniu i nic...


Nawet nie wiem co poradzić, bo u mnie przechodzi niezauważalnie.
Może dlatego, że X-y i KDE to jedyne czego nie kompiluję podczas
pierwszej instalacji  (aby mieć szybko środowisko graficzne).
Piszę 'pkg_add -r kde' i hula. Dopiero od pierwszej aktualizacji
(przeważnie następuje parę dni po inauguracji nowej wersji)
plus zapoznanie się z opcjami i ich zapis do /var/db/ports/

 

-- 
Bodek

Bodek wrote:

>> To ma taką zaletę, że wszystkie pakiety ustawiają się w odpowiedniej
>> kolejce - zgodnie z zależnosciami i nie widzę powodu, by dla kazdego
>> pakietu z osobna uruchamiać portupgrade.
> 
> Jak masz 'portupgrade a b c d ...' albo 'portupgrade -a'
> pewnie też się ustawiają, bo na pewno nie są kompilowane
> w kolejności wpisania czy w kolejności alfabetycznej.

Też kiedyś, na początku, robiłem to przez -a, ale później zacząłęm,
swoją metodą, bo mi za dużo śmieci wypluwał z -a. Ale nie mam nic
przeciw używaniu opcji -a czy innej, a jedynie uważam, że upgrejdowanie
każdego pakietu z osobna, to co najmniej przesada.

>> Rzadko zdażają mi się problemy z aktualizacją.
> 
> 1 Komputer desktop do wszystkiego, 1000 paczek, update
> prawie zawsze po włączeniu  - 90% aktualizacji to problemy.

Ja nie mam takich problemów ze swoim desktopem. Upgrejdy idą jak trzeba
i też robione są codzień "z rana". Casami tylko coś wyskoczy.
Może to probelm w czym innym? Może jest jakiś jeden, dwa porty,
które robią u Ciebe zamieszanie, a u mnie ich po prostu nie ma.

Kiedyś długo nie mogłem libxine skompilować i zastanawiałem się dlaczego.
Najpierw kląłem na FreeBSD team, że softu nie testują, a potem olałem to
nowe libxine, i uznałem że stare mi wystarcza :). Aż pewnego razu zupełnie
przypadkiem okazało się, że libxine mi się kompiluje, choć nowszej wersji
w portach od tamtego czasu nie było. Co było tego przyczyną?

Kilka tygodni wczesniej szukałem jakiegoś buga w jednym z portów i włączyłem
kompilację z opcją debug, a że port miał kilka zależnych bibliotek,
więc "tymczasowo" dałem to do make.conf i zapomniałem o tym. Kilka tygodni
później wyłączyłem tę opcję, a dzień później, ku mojemu zdziwieniu libxine
się skompilowało. Dopiero po chwili przypomniałem sobie "sprawie" opcji
w make.conf.

> Z KDE3 i KDE4 jednocześnie - żadnych problemów. I to jest dziwne,
> bo kobyła wielka i jak na nieskore do nowości FreeBSD dosyć
> szybko przygotowane do standardowej instalacji (debian, zazwyczaj
> szybszy w nowościach, potrafi wypuścić tę samą wersję parę
> miesięcy później)

Debian szybszy w nowościach? Od kiedy. No chyba, że chodzi o SID-a.
Nie, no mam w miarę świerzego Siduxa, ale KDE do niedawna było 3.9,
a 4 (4.1) to dopiero od kilkunastu dni jest dostępne.

Debiana 5.0 ostatnio (z półtorej tygodnia temu) też aktualizowałem i wyszło
mi, że wreszcie będe miał na debianie kde 3.10. Oczywiscię dla sportu
tego debiana aktualizowałem, nie żeby używać. ;)

>> Jak już pisałem rzadko mi się zdażają problemy z aktualizacjami, ale
> 
> dar/darzyć/zdarzenie - inaczej nie da rady zapamiętać :-)

Oj, czepiasz się. Już późno w nocy i słownik mi się wyłączył. ;)

>> przyznaję, że ostatnimi czasy coś się we FreeBSD popsuło. ;(
>> 
>> *)-x boost\*, -x boost_python, -x devel/boost i kilka innych, jakie mi
>> do głowy przyszły; próbowałem dawac jako pierwszą i ostatnią opcję w
>> poleceniu i nic...
> 
> 
> Nawet nie wiem co poradzić, bo u mnie przechodzi niezauważalnie.
> Może dlatego, że X-y i KDE to jedyne czego nie kompiluję podczas
> pierwszej instalacji  (aby mieć szybko środowisko graficzne).

Z pewnością nie masz "tego samego" boosta co ja mam, a tylko masz
tego z pythonem (devel/boost_python). Wówczas się nie złości.
Ja w C++ dziurgam conieco i mam devel/boost zainstalowane.
Co prawda to jeden czort, ale  ten z _python ma domyślnie kompilowane
wariacje pythonowe, a ten bez nie. Ja kompiluję "zwykłego" boosta dodając
mu opcję pythonowe i w efekcie wychodzi mi taki sam, ale port z KDE tego
nie rozpoznaje (nie sprawdza) i nahalnie próbuje dodawać tego drugiego,
po czym wysypuje się z komunikatem, że boost jest już zainstalowany,
odinstaluj poprzednią wersjię i ble ble ble...

-- 
Piotr Sietnik
s i e t p [@] p o c z t a [na] . o n e t . p l

PetruS <sietp@poczta.onet.pl> rzecze:
> Perla powinni już dawno wrzucić do basesystemu, bo jest tak samo potrzebny
> w systemie jak gcc, cut, grep czy awk.

 Przecież był i (IMO słusznie) wyrzucili. O cut, grep, awk nie ma sensu
dyskutować, a co do gcc, to jakiś kompilator w base systemie powinien
być (przynajmniej zdolny do skompilowania base systemu), ale na razie
nie ma alternatywy. Sądzę, że jak LLVM będzie już na wystarczającym
poziomie, to z base systemu zniknie i GCC.

-- 
am

PetruS <sietp@poczta.onet.pl> wrote:
> Perla powinni już dawno wrzucić do basesystemu

Był i wyrzucili. I słusznie.

p.

-- 
http://freedns.sgh.waw.pl/  -- bezpłatny DNS.
http://nerdquiz.sgh.waw.pl/ -- polska wersja quizu dla nerdów.
http://42.pl/u/ -- skracacz URL-i.

On Sun, 26 Apr 2009, PetruS wrote:

>>> Rzadko zdażają mi się problemy z aktualizacją.
>>
>> 1 Komputer desktop do wszystkiego, 1000 paczek, update
>> prawie zawsze po włączeniu  - 90% aktualizacji to problemy.
>
> Ja nie mam takich problemów ze swoim desktopem. Upgrejdy idą jak trzeba
> i też robione są codzień "z rana". Casami tylko coś wyskoczy.

upgrade na desktopie codziennie z rana?? przeciez to moze spowodowac 
zapasc calego systemu, chocby w przypadku ostatniego przejscia z Xorg 
1.4 poprzez calkowicie niestabilny 1.5 na w miare dzialajacy 1.6,

shio wrote:

> 
> 
> On Sun, 26 Apr 2009, PetruS wrote:
> 
>>>> Rzadko zdażają mi się problemy z aktualizacją.
>>>
>>> 1 Komputer desktop do wszystkiego, 1000 paczek, update
>>> prawie zawsze po włączeniu  - 90% aktualizacji to problemy.
>>
>> Ja nie mam takich problemów ze swoim desktopem. Upgrejdy idą jak trzeba
>> i też robione są codzień "z rana". Casami tylko coś wyskoczy.
> 
> upgrade na desktopie codziennie z rana?? przeciez to moze spowodowac
> zapasc calego systemu,

U mnie jakoś nie spowodowało. ;)

> chocby w przypadku ostatniego przejscia z Xorg 
> 1.4 poprzez calkowicie niestabilny 1.5 na w miare dzialajacy 1.6,

Przesada, Xorg to jeszcze nie cały system.

Problemy były, ale co mi tam? Jestem tak uzależniony od FreeBSD, że gorzej
by mi było gdybym ich nie miał.

Moje uzależnienie jest tak duże, że choć wiele mi brakuje we Free i ciągle
mnie kusi by wrócić do Linuksa, to nie mogę. Mam już kilkadziesiąt instalek
różnych dystrów i choć dość często próbuję je instalować, to zawsze kończy
się tak, że góra po dwóch dniach odzyskuję Free z backupów i się z nim
dalej męczę. :)

Siedem dwa tuż tuż, a ja z niecierpliwością czekam już na ósemkę.
- Aby do lata! :)))

-- 
Piotr Sietnik
s i e t p [@] p o c z t a [na] . o n e t . p l