Dan Lukes wrote on 01/14/2016 22:19:
On 01/14/16 20:06, Miroslav Lachman wrote:
Mozna mi neco unika, ale mam pocit, ze u me to tak funguje. Nebo je
to jeste neco jineho?
oniguruma4-4.7.1_1 ? orphaned: devel/oniguruma4
Probehne stazeni balicku a znovu kontrola zavislosti a konfliktu, kde to
pak spravne najde, ze onigurma5 je nahradou za onigurma4
To je pripad, kdy je jeden balicek nahrazovan jinym. Na reseni tehle
situace existuje specialni database (odvozena od soubor /usr/ports/MOVED).
To 'pkg upgrade' zvlada.
Ja mluvim o situaci, kdy mas na klientovi balicek, v portovem stroju je
jeho novejsi verze (nikoliv zcela jiny balicek deklarovany jako
naslednicky), jenze se z libovolnyho duvodu pri prekladu neprelozil
(nebo se jen nevytvoril balicek). Nebo ti ho 'pkg autoremove' smazal.
Proste tam neni.
Ja to teda zatim nijak nezkoumal, ale mel jsem za to, ze "orphaned" se
objevi prave v pripade, kdy ten balicek chybi v repozitari.
Vychazim z toho, ze "pkg" nevi nic o ports tree (na klientskem stroji
neni) a vsechny "indexy" jsou sestavene jen z toho, jake balicky mam v
repozitari.
Nebo mas pocit, ze se "pkg" nejakym zpusobem dostava k informacim o
zdrojovem ports tree? To se mi nejak nezda.
Co se tyce autoremove - to mi ze zacatku blblo a chtelo smazat treba
nejake PHP extensions, protoze se instalovaly jako zavislosti neceho,
ale pravdepodobne to byl jeste nejaky pozustatek chyby v databazi z pkg2ng.
Schvalne jsem nechal autoremove tyhle baliky smazat a pak je hned zase
vratil pres pkg install a od te doby mi je autoremove uz nechce mazat.
(to jen takovy tip, jak to "vyresit")
Mirek
--
FreeBSD mailing list ([email protected])
http://www.freebsd.cz/listserv/listinfo/users-l
