[csw-users] Migrating monitoring services from Linux - Munin server missing some files??

[Sebastian Kayser]

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