Dagobert Michelsen wrote on 13.02.2010 16:08: > Am 13.02.2010 um 15:59 schrieb Kaya Saman: >> this is my first attempt to download/install Cacti from the link you >> provided: >> Updated description file >> INTERNAL ERROR: cannot get remote version for CSWphp5 >> Perhaps your catalog is out of date >> INTERNAL ERROR: cannot get remote version for CSWap2modphp5 >> Perhaps your catalog is out of date >> INTERNAL ERROR: cannot get remote version for CSWphp5mysql >> Perhaps your catalog is out of date >> INTERNAL ERROR: cannot get remote version for CSWphp5snmp >> Perhaps your catalog is out of date >> INTERNAL ERROR: cannot get remote version for CSWphp5session >> Perhaps your catalog is out of date >> INTERNAL ERROR: cannot get remote version for CSWphp5sockets >> Perhaps your catalog is out of date >> INTERNAL ERROR: cannot get remote version for CSWcommon >> Perhaps your catalog is out of date >> No existing install of CSWcacti found. Installing... >> Trying >> http://mirror.opencsw.org/opencsw/testing/i386/5.11/cacti-0.8.7e,REV=2009.07.26-SunOS5.8-all-CSW.pkg.gz >> --16:54:50-- >> http://mirror.opencsw.org/opencsw/testing/i386/5.11/cacti-0.8.7e,REV=2009.07.26-SunOS5.8-all-CSW.pkg.gz >> => `cacti-0.8.7e,REV=2009.07.26-SunOS5.8-all-CSW.pkg.gz' > > pkg-get can not resolve dependencies across catalogs. Either install > these by > hand from the primary mirror or use pkgutil which handles this > transparently. > You can also install from the experimental-overlay from Jürgen which has > the dependencies layered on top: > http://mirror.opencsw.org/experimental.html#ja
Adding to Dago's comment. Testing has been our primary means of pushing single packages to the wider public for testing, before they were considered for release. There have been two issues with this: 1) pkg-get can't handle dependencies across catalogs, so packages in testing which rely on existing packages in current can trigger pkg-get errors like the ones above. You can use pkgutil instead, which is capable of resolving dependencies across multiple catalogs (plus more capable in general). But please see 2). 2) testing is used by many maintainers, and was so not only for public testing, but also for internal testing. Thus, the state of packages in testing varied from in-development to just-before-release. Now when you were told to install a just-before-release package A from testing by one maintainer and another maintainer independently put package B in testing that happened to be dependency of A, pkgutil would also install B (and B could be in the in-development state, potentially harming your system). To address 2), pkgutil was enhanced with the -N switch to only install one specific package without any dependencies. This however makes it more difficult if a maintainer wants you to test multiple interdependent packages from testing as he would need to spell out the exact order to install each package individually. We are currently in the progress of re-thinking the release and testing process. One step was to introduce the experimental repositories. They are isolated from each other, so work from one maintainer will not unwillingly interfere with work from another one. They are also fully self-contained, so they can be used with pkg-get (look into pkgutil though, it has replaced pkg-get on all my systems). So better use the experimental/ repository Dago pointed you to. Sorry for the inconveniences with testing/, expect it to go away in its current state soon. HTH Sebastian _______________________________________________ users mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/users
