Re: handling stale dependencies
Hello, Something went wrong earlier on, and portupgrade screwed up. It tried to upgrade png, got as far as uninstalling it, failed to install it and then failed to restore the backup and for some reason also thinks that rrdtool does not depend on graphics/png, while it does, unconditionally. Best thing to do when you see pkgdb mentioning stale dependencies is hit ctrl-c hard, fast and often. Then scroll up to see what it did wrong and try to figure out how to correct it's mess. What is at present the png version installed on your system and could you show the output of: grep 'DEPORIGIN: graphics/png' /var/db/pkg/*/+CONTENTS It reveals nothing but so far so good. Everything seems to work so I am not going to worry about it. I just don't remember. I may have installed then uninstalled png at some point but no idea if I did. I have actually started to run a journal of everything being done to the server - it should help in future! -- Zbigniew Szalbot www.lc-words.com smime.p7s Description: S/MIME Cryptographic Signature
Re: handling stale dependencies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Zbigniew Szalbot wrote: | Hello, | | I will appreciate your advice about how to best handle stale dependencies. Today I wanted to upgrade phpMyAdmin and I got a number of questions about stale dependencies. I eventually deleted all of them, but does this mean I need to upgrade ports which used this dependency (mailgraph-1.14_1, netpbm-10.26.52, p5-FuzzyOcr-devel-3.4.2_1, php5-gd-5.2.5_1, and rrdtool-1.2.26)? I am not sure what your asking... if your asking do you need png for phpMyAdmin the short answer is no... the long answer is yes because if you want to maintain the ports it depends on then they need png. Portupgrade uses an external DB (not the same one as pkg_* uses) and this is the one that pkgdb maintains. Which means that until you run pkgdb portupgrade will use the old depends... now if you not using portupgrade this is not an issue but since you are you need to make sure the two are in sync. That being said once you answered yes/all to Delete this? then any mention of the depend in pkgdb will be removed and if you had already done a make deinstall or pkg_delete then your fine all the way around (and by definition you already have because you will not get that question unless the port/package doesn't exist in the /var/db/pkg hierachy) | | Stale dependency: mailgraph-1.14_1 - png-1.2.27 (graphics/png): | Delete this? ([y]es/[n]o/[a]ll) [yes] | Deleted. | Stale dependency: netpbm-10.26.52 - png-1.2.27 (graphics/png): | Delete this? ([y]es/[n]o/[a]ll) [yes] | Deleted. | Stale dependency: p5-FuzzyOcr-devel-3.4.2_1 - png-1.2.27 (graphics/png): | Delete this? ([y]es/[n]o/[a]ll) [yes] | Deleted. | Stale dependency: pear-Image_Color-1.0.2_1 - png-1.2.27 (graphics/png): | Delete this? ([y]es/[n]o/[a]ll) [yes] | Deleted. | Stale dependency: pecl-pdflib-2.1.5 - png-1.2.27 (graphics/png): | Delete this? ([y]es/[n]o/[a]ll) [yes] | Deleted. | Stale dependency: php5-gd-5.2.5_1 - png-1.2.27 (graphics/png): | Delete this? ([y]es/[n]o/[a]ll) [yes] | Deleted. | Stale dependency: phpMyAdmin-2.11.5 - png-1.2.27 (graphics/png): | Delete this? ([y]es/[n]o/[a]ll) [yes] | Deleted. | Stale dependency: rrdtool-1.2.26 - png-1.2.27 (graphics/png): | Delete this? ([y]es/[n]o/[a]ll) [yes] | Deleted. | | I am not even sure png is installed. | $ pkg_info -Ix png | pkg_info: no packages match pattern(s) | | $ cat /usr/ports/graphics/png/distinfo | MD5 (libpng-1.2.28.tar.bz2) = c981a7014fc695e354d2f2cac3a6742e | SHA256 (libpng-1.2.28.tar.bz2) = 041c11048ea812f56d7042fbdfc3d7025c97a81f07ab20ebd0f50aecb47baccc | SIZE (libpng-1.2.28.tar.bz2) = 788156 | | Many thanks in advance! | -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkgasOUACgkQk8GFzCrQm4B5nQCdGTC1J9VxQ6q2+bOZFvuOxVvk cFkAn0VNZMqA0Z2RLGoyMMlpfPkHMhAb =bEax -END PGP SIGNATURE- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: handling stale dependencies
On Friday 02 May 2008 07:20:30 Zbigniew Szalbot wrote: Hello, I will appreciate your advice about how to best handle stale dependencies. Today I wanted to upgrade phpMyAdmin and I got a number of questions about stale dependencies. I eventually deleted all of them, but does this mean I need to upgrade ports which used this dependency (mailgraph-1.14_1, netpbm-10.26.52, p5-FuzzyOcr-devel-3.4.2_1, php5-gd-5.2.5_1, and rrdtool-1.2.26)? Stale dependency: mailgraph-1.14_1 - png-1.2.27 (graphics/png): Delete this? ([y]es/[n]o/[a]ll) [yes] Deleted. Something went wrong earlier on, and portupgrade screwed up. It tried to upgrade png, got as far as uninstalling it, failed to install it and then failed to restore the backup and for some reason also thinks that rrdtool does not depend on graphics/png, while it does, unconditionally. Best thing to do when you see pkgdb mentioning stale dependencies is hit ctrl-c hard, fast and often. Then scroll up to see what it did wrong and try to figure out how to correct it's mess. What is at present the png version installed on your system and could you show the output of: grep 'DEPORIGIN: graphics/png' /var/db/pkg/*/+CONTENTS -- Mel Problem with today's modular software: they start with the modules and never get to the software part. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
handling stale dependencies
Hello, I will appreciate your advice about how to best handle stale dependencies. Today I wanted to upgrade phpMyAdmin and I got a number of questions about stale dependencies. I eventually deleted all of them, but does this mean I need to upgrade ports which used this dependency (mailgraph-1.14_1, netpbm-10.26.52, p5-FuzzyOcr-devel-3.4.2_1, php5-gd-5.2.5_1, and rrdtool-1.2.26)? Stale dependency: mailgraph-1.14_1 - png-1.2.27 (graphics/png): Delete this? ([y]es/[n]o/[a]ll) [yes] Deleted. Stale dependency: netpbm-10.26.52 - png-1.2.27 (graphics/png): Delete this? ([y]es/[n]o/[a]ll) [yes] Deleted. Stale dependency: p5-FuzzyOcr-devel-3.4.2_1 - png-1.2.27 (graphics/png): Delete this? ([y]es/[n]o/[a]ll) [yes] Deleted. Stale dependency: pear-Image_Color-1.0.2_1 - png-1.2.27 (graphics/png): Delete this? ([y]es/[n]o/[a]ll) [yes] Deleted. Stale dependency: pecl-pdflib-2.1.5 - png-1.2.27 (graphics/png): Delete this? ([y]es/[n]o/[a]ll) [yes] Deleted. Stale dependency: php5-gd-5.2.5_1 - png-1.2.27 (graphics/png): Delete this? ([y]es/[n]o/[a]ll) [yes] Deleted. Stale dependency: phpMyAdmin-2.11.5 - png-1.2.27 (graphics/png): Delete this? ([y]es/[n]o/[a]ll) [yes] Deleted. Stale dependency: rrdtool-1.2.26 - png-1.2.27 (graphics/png): Delete this? ([y]es/[n]o/[a]ll) [yes] Deleted. I am not even sure png is installed. $ pkg_info -Ix png pkg_info: no packages match pattern(s) $ cat /usr/ports/graphics/png/distinfo MD5 (libpng-1.2.28.tar.bz2) = c981a7014fc695e354d2f2cac3a6742e SHA256 (libpng-1.2.28.tar.bz2) = 041c11048ea812f56d7042fbdfc3d7025c97a81f07ab20ebd0f50aecb47baccc SIZE (libpng-1.2.28.tar.bz2) = 788156 Many thanks in advance! -- Zbigniew Szalbot www.lc-words.com smime.p7s Description: S/MIME Cryptographic Signature
Stale Dependencies ??????
I've recently had a few problems with KDE 3.5.1, so recently upgraded to 3.5.3 via the ports. I have a port upgrade script which is producing the following output when executed. Stale dependency: gconf2-2.14.0_2 -- openldap-client-2.2.30 -- manually run 'pkgdb -F' to fix, or specify -O to force. now upgrading the required ports Stale dependency: gconf2-2.14.0_2 -- openldap-client-2.2.30 -- manually run 'pkgdb -F' to fix, or specify -O to force. Could someone please explain what is happening here. If I run pkgdb -F I get the following output (pressing enter to accept the default) luey# pkgdb -F --- Checking the package registry database Stale origin: 'devel/gnu-libtool': perhaps moved or obsoleted. - The port 'devel/gnu-libtool' was removed on 2006-06-05 because: Has expired: devel/libtool15 is now stock and should be used instead - Hint: gnu-libtool-1.5.20 is required by the following package(s): kdevelop-3.3.1_1 - Hint: checking for overwritten files... - No files installed by gnu-libtool-1.5.20 have been overwritten by other packages. Deinstall gnu-libtool-1.5.20 ? [no] Stale dependency: gconf2-2.14.0_2 - openldap-client-2.2.30 (net/openldap22-client): openldap-client-2.3.24 (score:76%) ? ([y]es/[n]o/[a]ll) [no] New dependency? (? to help): Skip this? ([y]es/[n]o/[a]ll) [yes] Skipped. Stale dependency: kde-3.5.3 - libexif-0.6.13 (graphics/libexif): libxslt-1.1.17 (score:17%) ? ([y]es/[n]o/[a]ll) [no] New dependency? (? to help): Skip this? ([y]es/[n]o/[a]ll) [yes] Skipped. Stale dependency: kde-3.5.3 - poppler-0.5.3 (graphics/poppler): popt-1.7_1 (score:18%) ? ([y]es/[n]o/[a]ll) [no] New dependency? (? to help): Skip this? ([y]es/[n]o/[a]ll) [yes] Skipped. Stale dependency: kde-3.5.3 - poppler-qt-0.5.3 (graphics/poppler-qt): popt-1.7_1 (score:18%) ? ([y]es/[n]o/[a]ll) [no] New dependency? (? to help): Skip this? ([y]es/[n]o/[a]ll) [yes] Skipped. Stale dependency: kdeartwork-3.5.1_1 - openldap-client-2.2.30 (net/openldap22-client): Skip this? ([y]es/[n]o/[a]ll) [yes] Stale dependency: kdesdk-3.5.1_1 - openldap-client-2.2.30 (net/openldap22-client): Skip this? ([y]es/[n]o/[a]ll) [yes] Stale dependency: kdeutils-3.5.1_1 - openldap-client-2.2.30 (net/openldap22-client): Skip this? ([y]es/[n]o/[a]ll) [yes] Stale dependency: kdevelop-3.3.1_1 - openldap-client-2.2.30 (net/openldap22-client): Skip this? ([y]es/[n]o/[a]ll) [yes] Stale dependency: libgsf-1.14.1 - openldap-client-2.2.30 (net/openldap22-client): Skip this? ([y]es/[n]o/[a]ll) [yes] Stale dependency: samba-libsmbclient-3.0.22 - openldap-client-2.2.30 (net/openldap22-client): Skip this? ([y]es/[n]o/[a]ll) [yes] Stale dependency: wv2-0.2.2_3 - openldap-client-2.2.30 (net/openldap22-client): Skip this? ([y]es/[n]o/[a]ll) [yes] - All new Yahoo! Mail The new Interface is stunning in its simplicity and ease of use. - PC Magazine ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Stale Dependencies ??????
On Saturday 24 June 2006 12:27, Robert Davison wrote: I've recently had a few problems with KDE 3.5.1, so recently upgraded to 3.5.3 via the ports. I have a port upgrade script which is producing the following output when executed. Stale dependency: gconf2-2.14.0_2 -- openldap-client-2.2.30 -- manually run 'pkgdb -F' to fix, or specify -O to force. now upgrading the required ports Stale dependency: gconf2-2.14.0_2 -- openldap-client-2.2.30 -- manually run 'pkgdb -F' to fix, or specify -O to force. Could someone please explain what is happening here. If I run pkgdb -F I get the following output (pressing enter to accept the default) luey# pkgdb -F --- Checking the package registry database Stale origin: 'devel/gnu-libtool': perhaps moved or obsoleted. - The port 'devel/gnu-libtool' was removed on 2006-06-05 because: Has expired: devel/libtool15 is now stock and should be used instead - Hint: gnu-libtool-1.5.20 is required by the following package(s): kdevelop-3.3.1_1 - Hint: checking for overwritten files... - No files installed by gnu-libtool-1.5.20 have been overwritten by other packages. Deinstall gnu-libtool-1.5.20 ? [no] You should be able to answer YES to this question. Stale dependency: gconf2-2.14.0_2 - openldap-client-2.2.30 (net/openldap22-client): openldap-client-2.3.24 (score:76%) ? ([y]es/[n]o/[a]ll) [no] New dependency? (? to help): Skip this? ([y]es/[n]o/[a]ll) [yes] Skipped. Stale dependency: kde-3.5.3 - libexif-0.6.13 (graphics/libexif): libxslt-1.1.17 (score:17%) ? ([y]es/[n]o/[a]ll) [no] New dependency? (? to help): Skip this? ([y]es/[n]o/[a]ll) [yes] Skipped. Stale dependency: kde-3.5.3 - poppler-0.5.3 (graphics/poppler): popt-1.7_1 (score:18%) ? ([y]es/[n]o/[a]ll) [no] New dependency? (? to help): Skip this? ([y]es/[n]o/[a]ll) [yes] Skipped. Stale dependency: kde-3.5.3 - poppler-qt-0.5.3 (graphics/poppler-qt): popt-1.7_1 (score:18%) ? ([y]es/[n]o/[a]ll) [no] New dependency? (? to help): Skip this? ([y]es/[n]o/[a]ll) [yes] Skipped. Stale dependency: kdeartwork-3.5.1_1 - openldap-client-2.2.30 (net/openldap22-client): Skip this? ([y]es/[n]o/[a]ll) [yes] Stale dependency: kdesdk-3.5.1_1 - openldap-client-2.2.30 (net/openldap22-client): Skip this? ([y]es/[n]o/[a]ll) [yes] Stale dependency: kdeutils-3.5.1_1 - openldap-client-2.2.30 (net/openldap22-client): Skip this? ([y]es/[n]o/[a]ll) [yes] Stale dependency: kdevelop-3.3.1_1 - openldap-client-2.2.30 (net/openldap22-client): Skip this? ([y]es/[n]o/[a]ll) [yes] Stale dependency: libgsf-1.14.1 - openldap-client-2.2.30 (net/openldap22-client): Skip this? ([y]es/[n]o/[a]ll) [yes] Stale dependency: samba-libsmbclient-3.0.22 - openldap-client-2.2.30 (net/openldap22-client): Skip this? ([y]es/[n]o/[a]ll) [yes] Stale dependency: wv2-0.2.2_3 - openldap-client-2.2.30 (net/openldap22-client): Skip this? ([y]es/[n]o/[a]ll) [yes] Try running: pkgdb --autofix That should take care of the easily fixed dependency problems. -- Gerard Seibert [EMAIL PROTECTED] Encyclopedia for sale by father. Son knows everything. pgpBwzGhREP2k.pgp Description: PGP signature
Re: Stale Dependencies ??????
On Jun 24, 2006, at 9:41 AM, Gerard Seibert wrote: On Saturday 24 June 2006 12:27, Robert Davison wrote: I've recently had a few problems with KDE 3.5.1, so recently upgraded to 3.5.3 via the ports. I have a port upgrade script which is producing the following output when executed. Stale dependency: gconf2-2.14.0_2 -- openldap-client-2.2.30 -- manually run 'pkgdb -F' to fix, or specify -O to force. now upgrading the required ports Stale dependency: gconf2-2.14.0_2 -- openldap-client-2.2.30 -- manually run 'pkgdb -F' to fix, or specify -O to force. Could someone please explain what is happening here. If I run pkgdb -F I get the following output (pressing enter to accept the default) I've had the hardest time understanding what pkgdb asks. This is the only article I've found which makes some sense to me: http://www.onlamp.com/pub/a/bsd/2001/11/29/Big_Scary_Daemons.html?page=1 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Stale Dependencies ??????
On Saturday 24 June 2006 13:11, vayu wrote: On Jun 24, 2006, at 9:41 AM, Gerard Seibert wrote: //snip// I've had the hardest time understanding what pkgdb asks. This is the only article I've found which makes some sense to me: http://www.onlamp.com/pub/a/bsd/2001/11/29/Big_Scary_Daemons.html?page=1 I once had a problem on FSBD 5.4 that was so bad that I finally used portmanager to clean it up. portmanager -u -f -y -l That corrected everything. However, it did take a couple of days to rebuild the entire system. Ciao! -- Gerard Seibert [EMAIL PROTECTED] Reporter, n.: A writer who guesses his way to the truth and dispels it with a tempest of words. Ambrose Bierce, The Devil's Dictionary ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Fixing stale dependencies with pkgdb
Hi, Stale dependency: gnomenettool-2.14.1_1,1 - openldap-client-2.2.30 (net/openldap22-client): openldap-sasl-server-2.2.30 ? ([y]es/[n]o/[a]ll) [yes] Does answering [a]ll here imply yes for only this category of dependencies (openldap-sasl-server-2.2.30 replacing net/openldap22-client) or for all upcoming selections for all stale dependencies? Thanks, Duane Whitty -- [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: stale dependencies in pkgdb
Andrew wrote:
On Fri, 2006-02-10 at 11:42 -0500, Robert Huff wrote:
Andrew writes:
I've run pkgdb -F as portupgrade suggests, deleting stale
dependencies, but they seem to keep reappearing.
I'm not an expert on pkgdb, but I'm pretty sure that's the way
it works.
You need to fix, not delete, the stale dependencies. This may
take some effort the first time around.
Beyond that, I question the wisdom of any automatic
solution. There are definitely times when I do _not_ want to accept
the fixes proposed by pkgdb -F.
My apologies; I re-read the man pages for portupgrade and pkgdb and I
think I understand what's going on now. Thanks anyway...
-Andrew
A good solution in the long term, rather than fixing dependencies every
time you do an upgrade, is to look at the ALT_PKGDEP section of
pkgtools.conf. Here is how i addressed the cdrtools dependency you
mentioned.
ALT_PKGDEP = {
'cdr-tools*' = 'cjk-cdrtools*',
'pcre-*' = 'pcre-utf8',
}
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Long list of stale dependencies for tomcat55 port
Does anyone know how my Tomcat installation on a 5.4 box has ended up including the following as tomcat dependencies? atk-1.10.3 libXft-2.1.7 xorg-fonts-encodings-6.9.0_1 desktop-file-utils-0.10_3 pango-1.10.3 glib-2.8.6 cairo-1.0.2_1 gtk-2.8.12 mozilla-1.7.12_5,2 tiff-3.8.0 bitstream-vera-1.10_2 I don't even know what half of them do. I've deleted all the stale dependencies because freshports.org says the only run-time dependency is java/jdk14 (jdk15 on my machine). Is this right? Ashley ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Long list of stale dependencies for tomcat55 port
On 13 Feb 2006, at 11:28, Ashley Moran wrote: Does anyone know how my Tomcat installation on a 5.4 box has ended up including the following as tomcat dependencies? atk-1.10.3 libXft-2.1.7 xorg-fonts-encodings-6.9.0_1 desktop-file-utils-0.10_3 pango-1.10.3 glib-2.8.6 cairo-1.0.2_1 gtk-2.8.12 mozilla-1.7.12_5,2 tiff-3.8.0 bitstream-vera-1.10_2 Nope. I don't even know what half of them do. I've deleted all the stale dependencies because freshports.org says the only run-time dependency is java/jdk14 (jdk15 on my machine). Is this right? According to make, yes: [EMAIL PROTECTED]/www/tomcat55} % make -V RUN_DEPENDS /usr/local/jdk1.4.2/bin/java:/usr/ports/java/jdk14 Ceri -- That must be wonderful! I don't understand it at all. -- Moliere PGP.sig Description: This is a digitally signed message part
Re: stale dependencies in pkgdb
On Friday 10 February 2006 20:35, Andrew wrote: think I've got it now. I believe I was correct in thinking that portupgrade usually takes care of dependencies; the portion that I was missing was that pkgdb catches what discrepancies do appear between what is installed and what is required. Try portmanager instead. Portupgrade, and the other package-tools installed by the portupgrade port, are highly dependent on the package database and need it to self-consistent. Portmanger uses the information in the port makefiles instead, which makes it much more robust. This also means it's working from information about how thing should be, rather than how they are/were. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
stale dependencies in pkgdb
Hello, I am trying to use a combination of portaudit and portupgrade to automatically maintain installed packages on my system, but portupgrade often hangs on stale dependencies. I've run pkgdb -F as portupgrade suggests, deleting stale dependencies, but they seem to keep reappearing. I guess I'm a little unclear about what a stale dependency consists of and how to fix it. Pointers to relevant documentation and/or explanations would be greatly appreciated! Thanks, Andrew ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
stale dependencies in pkgdb
Andrew writes: I've run pkgdb -F as portupgrade suggests, deleting stale dependencies, but they seem to keep reappearing. I'm not an expert on pkgdb, but I'm pretty sure that's the way it works. You need to fix, not delete, the stale dependencies. This may take some effort the first time around. Beyond that, I question the wisdom of any automatic solution. There are definitely times when I do _not_ want to accept the fixes proposed by pkgdb -F. Robert Huff ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: stale dependencies in pkgdb
On Fri, 2006-02-10 at 11:42 -0500, Robert Huff wrote: Andrew writes: I've run pkgdb -F as portupgrade suggests, deleting stale dependencies, but they seem to keep reappearing. I'm not an expert on pkgdb, but I'm pretty sure that's the way it works. You need to fix, not delete, the stale dependencies. This may take some effort the first time around. Beyond that, I question the wisdom of any automatic solution. There are definitely times when I do _not_ want to accept the fixes proposed by pkgdb -F. I guess what is unclear to me is how I go about fixing the stale dependencies. I was under the impression that portupgrade would take care of the dependencies for a particular port, and the stale dependency was just an error in the package database (pkgdb). Is this not the case? Thank-you, Andrew ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: stale dependencies in pkgdb
On Friday 10 February 2006 12:41, Andrew wrote: On Fri, 2006-02-10 at 11:42 -0500, Robert Huff wrote: Andrew writes: I've run pkgdb -F as portupgrade suggests, deleting stale dependencies, but they seem to keep reappearing. I'm not an expert on pkgdb, but I'm pretty sure that's the way it works. You need to fix, not delete, the stale dependencies. This may take some effort the first time around. Beyond that, I question the wisdom of any automatic solution. There are definitely times when I do _not_ want to accept the fixes proposed by pkgdb -F. I guess what is unclear to me is how I go about fixing the stale dependencies. I was under the impression that portupgrade would take care of the dependencies for a particular port, and the stale dependency was just an error in the package database (pkgdb). Is this not the case? Thank-you, Andrew ___ A stale dependency can be a required program that's old, or it can be that there are two versions of the required program listed as installed in pkgdb, or it can be the required program was removed by another program and something else installed in its place and the dependcies not upgraded in pkgdb. 'pkgdb -F' will fix the problems it can safely fix. What it won't fix is a dependcency on a program that's been removed. You need to look at that message and figure out what's going on and correct the problem. Skipping or deleting the dependency is not taking care of the problem, it's just getting out of 'pkgdb -F'. Portupgrade - depending on how you used it - takes care of dependcies. A stale dependency is not an error in pkgdb. Something is wrong and you have to fix it. By the way, portaudit is a fine tool, but sometimes it gets in the way of what you want to do. It can prevent you from installing or upgrading some program that you want to. I can't say you would be better off without it, but I very seldom use it. Don ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: stale dependencies in pkgdb
On Fri, 2006-02-10 at 11:42 -0500, Robert Huff wrote: Andrew writes: I've run pkgdb -F as portupgrade suggests, deleting stale dependencies, but they seem to keep reappearing. I'm not an expert on pkgdb, but I'm pretty sure that's the way it works. You need to fix, not delete, the stale dependencies. This may take some effort the first time around. Beyond that, I question the wisdom of any automatic solution. There are definitely times when I do _not_ want to accept the fixes proposed by pkgdb -F. My apologies; I re-read the man pages for portupgrade and pkgdb and I think I understand what's going on now. Thanks anyway... -Andrew ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: stale dependencies in pkgdb
On Fri, 2006-02-10 at 15:11 -0500, Robert Huff wrote: Andrew writes: I guess what is unclear to me is how I go about fixing the stale dependencies. I was under the impression that portupgrade would take care of the dependencies for a particular port, and the stale dependency was just an error in the package database (pkgdb). Is this not the case? My understanding of how things work: Consider two ports a and b, such that a-4.6 is a dependency for b-2.2. If a updates to 4.7, and I run portupgrade -r a, b will also be updated. But if I run portupgrade a (or there's a bug in the programs/ scripts) b will not update ... and pkgdb will complain about about a stale (i.e. unsatisified) dependency. This also happens when you replace one port with another that provides the same functionality. For example: many gnome ports depend on openldap. But I use openldap-sasl - and every time I update one of those ports I have to manually correct the dependency. (There's probably a way to do that automatically, but I haven't figured out how.) And now there's a stale dependency. This can be expecially frustrating if the dependant port hasn't been updated for years; the required port may have been upgraded beyond recognition, no longer available, absorbed into another port, etc.. As to how, try this as a first approximation. Run [kgdb -f, and reply no to all changes. Write down the port:dependency pairs, and then anaylze the dependencies. Has it been installed. but not registered? Replaced by a newer version? Two useful files are /usr/ports/UPDATING and /usr/ports/MOVED. My response here is mostly guesswork, educated by several years of doing this and sometimes asking for help. In the case above, fixing a-4.6 with a-4.7 is usually a no-brainer. Fixing a-4.6 with a-5.0, however, would require reseaech (and warrant keeping a backup of the pkgdb). Sorry; just fired off a message to the list before I got this one... Anyway, I think I've got it now. I believe I was correct in thinking that portupgrade usually takes care of dependencies; the portion that I was missing was that pkgdb catches what discrepancies do appear between what is installed and what is required. One of the ports that was giving me troubles was gamin; which I've just noticed seems to be similar to your situation with openldap-sasl (gamin/fam). Another was cdrtools (cdrtools/cjk-cdrtools). I've corrected both manually using pkgdb -F, which I think solves my problem (for now, at least :-) ). Thank you for your help! -Andrew ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: stale dependencies in pkgdb
--- Andrew [EMAIL PROTECTED] wrote: On Fri, 2006-02-10 at 11:42 -0500, Robert Huff wrote: Andrew writes: I've run pkgdb -F as portupgrade suggests, deleting stale dependencies, but they seem to keep reappearing. I'm not an expert on pkgdb, but I'm pretty sure that's the way it works. You need to fix, not delete, the stale dependencies. This may take some effort the first time around. Beyond that, I question the wisdom of any automatic solution. There are definitely times when I do _not_ want to accept the fixes proposed by pkgdb -F. My apologies; I re-read the man pages for portupgrade and pkgdb and I think I understand what's going on now. Ok, but be more careful next time. __ Find your next car at http://autos.yahoo.ca ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portssystem stale dependencies
Sunday 20 November 2005 03:18 skrev RW: On Saturday 19 November 2005 10:37, Philip Lykke Carlsen wrote: .. does anyone know why the problem of stale dependencies in the package system occurs?.. it's just.. the system won't let you install any given port/package without having met all the dependencies.. That's not entirely true, it's really only portupgrade and it's associated tools that have a serious problem with stale dependencies. Portmanager is much more forgiving, as is direct make install installation. Well, then I think that I'll give portmanager a try.. thanks :-) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
portssystem stale dependencies
.. does anyone know why the problem of stale dependencies in the package system occurs?.. it's just.. the system won't let you install any given port/package without having met all the dependencies.. just how does it _forget_ that it just installed some package?.. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portssystem stale dependencies
On Sat, Nov 19, 2005 at 11:37:45AM +0100, Philip Lykke Carlsen wrote: .. does anyone know why the problem of stale dependencies in the package system occurs?.. it's just.. the system won't let you install any given port/package without having met all the dependencies.. just how does it _forget_ that it just installed some package?.. This portupgrade error condition happens when you install/deinstall/modify ports by some other means than by using the portupgrade tools. It's not that it forgets, but that portupgrade never knew about the changes in the first place, so you have to do some work to teach it. Kris pgpzcofWioMg9.pgp Description: PGP signature
Re: portssystem stale dependencies
On Saturday 19 November 2005 10:37, Philip Lykke Carlsen wrote: .. does anyone know why the problem of stale dependencies in the package system occurs?.. it's just.. the system won't let you install any given port/package without having met all the dependencies.. That's not entirely true, it's really only portupgrade and it's associated tools that have a serious problem with stale dependencies. Portmanager is much more forgiving, as is direct make install installation. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portssystem stale dependencies
On Saturday 19 November 2005 10:37, Philip Lykke Carlsen wrote: .. does anyone know why the problem of stale dependencies in the package system occurs?.. it's just.. the system won't let you install any given port/package without having met all the dependencies.. just how does it _forget_ that it just installed some package?.. It doesn't forget but it does submit. These are tools that come with portupgrade. During pkgdb -F you can always delete (CTRL+D) any dependency you don't like. Just force it if you have to. Almost always it comes from having a certain combination of ports installed where an actual update by version by one port doesn't really matter but the portupgrade system has it registered and so thinks it may do so. In other cases it just may or may not matter but usually you're running a portupgrade -a anyway so it'll be settled when done. In other cases if something's left behind or broken or so, deleting the dependency (and perhaps it's picked pu again later at your portupgrading) will be fine also. Just delete the pkgdb -F problem deps :) Dan ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portupgrade stale dependencies
On 10/31/05, John DeStefano [EMAIL PROTECTED] wrote: On 10/30/05, Andrew P. [EMAIL PROTECTED] wrote: On 10/31/05, John DeStefano [EMAIL PROTECTED] wrote: On 10/29/05, Andrew P. [EMAIL PROTECTED] wrote: On 10/29/05, John DeStefano [EMAIL PROTECTED] wrote: Needless to say, this process wasn't much fun. What can I do to keep this from happening again? What can/can't I safely include in cron to automate database and index maintenance? cvsup or portsnap, then portsdb -uUF. Work under any circumstances, leave you with updated ports tree and indexes. If I were to continue to use portsnap, which arguments can I safely add to /etc/crontab? I know portsnap cron should be safe, but if I want to completely automate the update process (not for installing packages, but for keeping the ports tree, database, and indexes current), should I also add an entry for portsnap update and portsdb -uUF? You can also try portupgrade -aF (prefetches needed files to speed up manual upgrade at a later time) and portsclean -DP (removes sources and packages which become outdated due to ports tree updates). Would you also recommend cron entries for these two commands? I used to use a cron job to run cvsup, and I'd like to implement a better, more complete automated solution, so I don't tangle up my system's packages and dependencies again. I think the best way is to create a shell script, like this: #!/bin/sh /usr/local/sbin/portsnap cron \ /usr/local/sbin/portsnap update \ /usr/local/sbin/portsdb -uUF \ /usr/local/sbin/portupgrade -aF \ /usr/local/sbin/portsclean -DP Perfect... I had everything but the conditionals... thanks! and run it at an hour, when you're most unlikely to perform any kind of port upgrading. As portsnap manpage warns, if both portsnap (in the process of update) and portupgrade ever happen to access the same directory at once, it might ruin your ports tree. You'll have to do portsnap extract after that. You can leave out portsclean and run it manually, because it can create some load (which is not desirable on a production server). I run this script daily at 8-9 in the morning (I usually start messing with servers after 11). It never failed, and it always keeps everything up-to-date. My server is not production, as it's just my personal web/database server; I'm the only one who would be running any updates. So I should be okay with this procedure, and I'll manually update any ports of note. Just one problem I saw thus far, with portsclean I think... Cleaning out /usr/ports/packages... cd: can't cd to /usr/ports/packages/All find: /usr/ports/packages: No such file or directory Would this be related to one of the advanced topics you mentioned earlier about pkgtools.conf? ;) Do I need to define some variables? I would guess the directory error to have been caused by a combination of the variables PORTSDIR (which looks okay at /usr/ports) and PACKAGES (which seems to need a /packages dir beneath PORTSDIR ?). Thanks, ~John No, it's not advanced at all :-) You just don't have the directory. Create it, if you want to. When you run make package or portupgrade -p something, a package is created in your current directory, unless /usr/ports/packages exists. If it does, the package is created there, and some hierarchy is kept, too. So it's convenient to have that dir, if you ever use packages. Of course, /usr/ports/packages is just the default. You can change PACKAGES to whatever you like. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portupgrade stale dependencies
On 10/31/05, John DeStefano [EMAIL PROTECTED] wrote: On 10/31/05, Andrew P. [EMAIL PROTECTED] wrote: On 10/31/05, John DeStefano [EMAIL PROTECTED] wrote: On 10/30/05, Andrew P. [EMAIL PROTECTED] wrote: On 10/31/05, John DeStefano [EMAIL PROTECTED] wrote: On 10/29/05, Andrew P. [EMAIL PROTECTED] wrote: On 10/29/05, John DeStefano [EMAIL PROTECTED] wrote: Needless to say, this process wasn't much fun. What can I do to keep this from happening again? What can/can't I safely include in cron to automate database and index maintenance? cvsup or portsnap, then portsdb -uUF. Work under any circumstances, leave you with updated ports tree and indexes. If I were to continue to use portsnap, which arguments can I safely add to /etc/crontab? I know portsnap cron should be safe, but if I want to completely automate the update process (not for installing packages, but for keeping the ports tree, database, and indexes current), should I also add an entry for portsnap update and portsdb -uUF? You can also try portupgrade -aF (prefetches needed files to speed up manual upgrade at a later time) and portsclean -DP (removes sources and packages which become outdated due to ports tree updates). Would you also recommend cron entries for these two commands? I used to use a cron job to run cvsup, and I'd like to implement a better, more complete automated solution, so I don't tangle up my system's packages and dependencies again. I think the best way is to create a shell script, like this: #!/bin/sh /usr/local/sbin/portsnap cron \ /usr/local/sbin/portsnap update \ /usr/local/sbin/portsdb -uUF \ /usr/local/sbin/portupgrade -aF \ /usr/local/sbin/portsclean -DP Perfect... I had everything but the conditionals... thanks! and run it at an hour, when you're most unlikely to perform any kind of port upgrading. As portsnap manpage warns, if both portsnap (in the process of update) and portupgrade ever happen to access the same directory at once, it might ruin your ports tree. You'll have to do portsnap extract after that. You can leave out portsclean and run it manually, because it can create some load (which is not desirable on a production server). I run this script daily at 8-9 in the morning (I usually start messing with servers after 11). It never failed, and it always keeps everything up-to-date. My server is not production, as it's just my personal web/database server; I'm the only one who would be running any updates. So I should be okay with this procedure, and I'll manually update any ports of note. Just one problem I saw thus far, with portsclean I think... Cleaning out /usr/ports/packages... cd: can't cd to /usr/ports/packages/All find: /usr/ports/packages: No such file or directory Would this be related to one of the advanced topics you mentioned earlier about pkgtools.conf? ;) Do I need to define some variables? I would guess the directory error to have been caused by a combination of the variables PORTSDIR (which looks okay at /usr/ports) and PACKAGES (which seems to need a /packages dir beneath PORTSDIR ?). Thanks, ~John No, it's not advanced at all :-) You just don't have the directory. Create it, if you want to. When you run make package or portupgrade -p something, a package is created in your current directory, unless /usr/ports/packages exists. If it does, the package is created there, and some hierarchy is kept, too. So it's convenient to have that dir, if you ever use packages. Of course, /usr/ports/packages is just the default. You can change PACKAGES to whatever you like. Thanks Andrew. You're right: that's not advanced, even for me! If that dir needs to have a specific set of permissions, please let me know; otherwise, I think I'm all set, aside from asking where I might read more about the ports/packages system that what's in the handbook and man pages. Thanks again for your help. ~John The default (755) permissions should be ok. The ultimate (more or less) ports/packages documentation consists of: ports(7) make(1) pkg_add(1) pkg_create(1) pkg_delete(1) pkg_info(1) pkg_version(1) /usr/ports/Mk/* The Porter's Handbook The FreeBSD Handbook (Packages and Ports) pib(1), portaudit(1), portcheckout(1), portlint(1) portupgrade(1), etc - depending on what tools you have installed. ports@ mailing list archives and various makefiles throughout the system are also valuable sources of documentation. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL
Re: portupgrade stale dependencies
On 10/29/05, Andrew P. [EMAIL PROTECTED] wrote: On 10/29/05, John DeStefano [EMAIL PROTECTED] wrote: Needless to say, this process wasn't much fun. What can I do to keep this from happening again? What can/can't I safely include in cron to automate database and index maintenance? cvsup or portsnap, then portsdb -uUF. Work under any circumstances, leave you with updated ports tree and indexes. If I were to continue to use portsnap, which arguments can I safely add to /etc/crontab? I know portsnap cron should be safe, but if I want to completely automate the update process (not for installing packages, but for keeping the ports tree, database, and indexes current), should I also add an entry for portsnap update and portsdb -uUF? You can also try portupgrade -aF (prefetches needed files to speed up manual upgrade at a later time) and portsclean -DP (removes sources and packages which become outdated due to ports tree updates). Would you also recommend cron entries for these two commands? I used to use a cron job to run cvsup, and I'd like to implement a better, more complete automated solution, so I don't tangle up my system's packages and dependencies again. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portupgrade stale dependencies
On 10/31/05, John DeStefano [EMAIL PROTECTED] wrote: On 10/29/05, Andrew P. [EMAIL PROTECTED] wrote: On 10/29/05, John DeStefano [EMAIL PROTECTED] wrote: Needless to say, this process wasn't much fun. What can I do to keep this from happening again? What can/can't I safely include in cron to automate database and index maintenance? cvsup or portsnap, then portsdb -uUF. Work under any circumstances, leave you with updated ports tree and indexes. If I were to continue to use portsnap, which arguments can I safely add to /etc/crontab? I know portsnap cron should be safe, but if I want to completely automate the update process (not for installing packages, but for keeping the ports tree, database, and indexes current), should I also add an entry for portsnap update and portsdb -uUF? You can also try portupgrade -aF (prefetches needed files to speed up manual upgrade at a later time) and portsclean -DP (removes sources and packages which become outdated due to ports tree updates). Would you also recommend cron entries for these two commands? I used to use a cron job to run cvsup, and I'd like to implement a better, more complete automated solution, so I don't tangle up my system's packages and dependencies again. I think the best way is to create a shell script, like this: #!/bin/sh /usr/local/sbin/portsnap cron \ /usr/local/sbin/portsnap update \ /usr/local/sbin/portsdb -uUF \ /usr/local/sbin/portupgrade -aF \ /usr/local/sbin/portsclean -DP and run it at an hour, when you're most unlikely to perform any kind of port upgrading. As portsnap manpage warns, if both portsnap (in the process of update) and portupgrade ever happen to access the same directory at once, it might ruin your ports tree. You'll have to do portsnap extract after that. You can leave out portsclean and run it manually, because it can create some load (which is not desirable on a production server). I run this script daily at 8-9 in the morning (I usually start messing with servers after 11). It never failed, and it always keeps everything up-to-date. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portupgrade stale dependencies
On 10/30/05, Andrew P. [EMAIL PROTECTED] wrote: On 10/31/05, John DeStefano [EMAIL PROTECTED] wrote: On 10/29/05, Andrew P. [EMAIL PROTECTED] wrote: On 10/29/05, John DeStefano [EMAIL PROTECTED] wrote: Needless to say, this process wasn't much fun. What can I do to keep this from happening again? What can/can't I safely include in cron to automate database and index maintenance? cvsup or portsnap, then portsdb -uUF. Work under any circumstances, leave you with updated ports tree and indexes. If I were to continue to use portsnap, which arguments can I safely add to /etc/crontab? I know portsnap cron should be safe, but if I want to completely automate the update process (not for installing packages, but for keeping the ports tree, database, and indexes current), should I also add an entry for portsnap update and portsdb -uUF? You can also try portupgrade -aF (prefetches needed files to speed up manual upgrade at a later time) and portsclean -DP (removes sources and packages which become outdated due to ports tree updates). Would you also recommend cron entries for these two commands? I used to use a cron job to run cvsup, and I'd like to implement a better, more complete automated solution, so I don't tangle up my system's packages and dependencies again. I think the best way is to create a shell script, like this: #!/bin/sh /usr/local/sbin/portsnap cron \ /usr/local/sbin/portsnap update \ /usr/local/sbin/portsdb -uUF \ /usr/local/sbin/portupgrade -aF \ /usr/local/sbin/portsclean -DP Perfect... I had everything but the conditionals... thanks! and run it at an hour, when you're most unlikely to perform any kind of port upgrading. As portsnap manpage warns, if both portsnap (in the process of update) and portupgrade ever happen to access the same directory at once, it might ruin your ports tree. You'll have to do portsnap extract after that. You can leave out portsclean and run it manually, because it can create some load (which is not desirable on a production server). I run this script daily at 8-9 in the morning (I usually start messing with servers after 11). It never failed, and it always keeps everything up-to-date. My server is not production, as it's just my personal web/database server; I'm the only one who would be running any updates. So I should be okay with this procedure, and I'll manually update any ports of note. Just one problem I saw thus far, with portsclean I think... Cleaning out /usr/ports/packages... cd: can't cd to /usr/ports/packages/All find: /usr/ports/packages: No such file or directory Would this be related to one of the advanced topics you mentioned earlier about pkgtools.conf? ;) Do I need to define some variables? I would guess the directory error to have been caused by a combination of the variables PORTSDIR (which looks okay at /usr/ports) and PACKAGES (which seems to need a /packages dir beneath PORTSDIR ?). Thanks, ~John ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portupgrade stale dependencies
On 10/29/05, John DeStefano [EMAIL PROTECTED] wrote: Needless to say, this process wasn't much fun. What can I do to keep this from happening again? What can/can't I safely include in cron to automate database and index maintenance? cvsup or portsnap, then portsdb -uUF. Work under any circumstances, leave you with updated ports tree and indexes. You can also try portupgrade -aF (prefetches needed files to speed up manual upgrade at a later time) and portsclean -DP (removes sources and packages which become outdated due to ports tree updates). ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portupgrade stale dependencies
On Oct 28, 2005, at 7:31 PM, John DeStefano wrote: cd /usr/ports/www/apache20 make deinstall make clean make reinstall See what happens. Talk about strange: # cd /usr/ports/www/apache20/ # make deinstall === Deinstalling for www/apache20 === apache not installed, skipping # make -V PKGNAME apache-2.0.55 # pkg_info | grep apache apache-2.0.48 Version 2 of the extremely popular Apache http server # apachectl -v Server version: Apache/2.0.48 Server built: Nov 19 2003 22:44:21 OK. the try #make install what happens? - Eric F Crist Secure Computing Networks http://www.secure-computing.net ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portupgrade stale dependencies
I ended up deinstalling that apache installation (which I was not keen on doing), and installing the apache20 port (which was the same version (2.0.55) as the apache2 port ?), and, thankfully, it's working fine. I'm also now able to run both 'pkgdb -F'and 'portsdb -Uu' without ANY errors (except for a few 'Duplicate INDEX entry' warnings). Needless to say, this process wasn't much fun. What can I do to keep this from happening again? What can/can't I safely include in cron to automate database and index maintenance? Thanks to all. What I do for critical system ports is a manual upgrade. I have never trusted any of the port management tools. I suggest you pay attention to bugtracker and some other sites. When you see a compelling reason to upgrade, do it manually. The process I use is what I described in an earlier post: #cd /usr/ports/port-to-upgrade make deinstall #make install #restart whatever port I just upgraded HTH - Eric F Crist Secure Computing Networks http://www.secure-computing.net ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portupgrade stale dependencies
On 10/28/05, Michael C. Shultz [EMAIL PROTECTED] wrote: On Thursday 27 October 2005 18:49, Eric F Crist wrote: On Oct 27, 2005, at 8:32 PM, John DeStefano wrote: On 10/27/05, Andrew P. [EMAIL PROTECTED] wrote: On 10/27/05, John DeStefano [EMAIL PROTECTED] wrote: After clearing out the ports, updating ports (with portsnap) and source, and rebuilding the system and kernel... it seemed the ultimate problem was actually a dependency of the package to apache1.3. After I ran 'pkgdb -F' and fixed this dependency to point to apache2.1, but I still had trouble installing ports. At this point, what usually works for me is to: #cd /usr rm -rf ./ports #mkdir ./ports cvsup /root/ports-supfile The above will delete your ENTIRE ports tree, provided it's kept in / usr/ports and as long as you use cvsup (and your ports supfile is / root/ports-supfile as mine is). When a whole bunch of ports stop working, I find this is the easiest thing to do. The other thing I do is run a cron job every week that updates, via cvsup, the ports tree. About once a year I perform the above, mostly to clean out the crap. Re-downloading your entire ports tree will be quicker if you don't use the ports-all tag and actually define which port segments you are interested in. For example, there's no real reason to download all the x11/kde/gnome crap if you're doing this on a headless server that isn't going to serve X. HTH Replacing /usr/ports won't fix his problems, they reside in /var/db/pkg. I may be a bit biased but I reaaly think John D. should try running portmanager -u (ports/sysutils/portmanager). Stale dependencies is a non issue for portmanager. -Mike ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] I don't think that stale dependencies are an issue for portupgrade as well, just add -O to the command- line. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re[2]: portupgrade stale dependencies
On Friday, October 28, 2005 3:25:14 AM, Andrew P. [EMAIL PROTECTED] Subject: Re: portupgrade stale dependencies Wrote these words of wisdom: On 10/28/05, Michael C. Shultz [EMAIL PROTECTED] wrote: On Thursday 27 October 2005 18:49, Eric F Crist wrote: On Oct 27, 2005, at 8:32 PM, John DeStefano wrote: On 10/27/05, Andrew P. [EMAIL PROTECTED] wrote: On 10/27/05, John DeStefano [EMAIL PROTECTED] wrote: After clearing out the ports, updating ports (with portsnap) and source, and rebuilding the system and kernel... it seemed the ultimate problem was actually a dependency of the package to apache1.3. After I ran 'pkgdb -F' and fixed this dependency to point to apache2.1, but I still had trouble installing ports. At this point, what usually works for me is to: #cd /usr rm -rf ./ports #mkdir ./ports cvsup /root/ports-supfile The above will delete your ENTIRE ports tree, provided it's kept in / usr/ports and as long as you use cvsup (and your ports supfile is / root/ports-supfile as mine is). When a whole bunch of ports stop working, I find this is the easiest thing to do. The other thing I do is run a cron job every week that updates, via cvsup, the ports tree. About once a year I perform the above, mostly to clean out the crap. Re-downloading your entire ports tree will be quicker if you don't use the ports-all tag and actually define which port segments you are interested in. For example, there's no real reason to download all the x11/kde/gnome crap if you're doing this on a headless server that isn't going to serve X. HTH Replacing /usr/ports won't fix his problems, they reside in /var/db/pkg. I may be a bit biased but I reaaly think John D. should try running portmanager -u (ports/sysutils/portmanager). Stale dependencies is a non issue for portmanager. -Mike I don't think that stale dependencies are an issue for portupgrade as well, just add -O to the command- line. * REPLY SEPARATOR * On 10/11/2005 5:29:42 PM, Gerard Replied: Personally, I feel that portmanager does a much better job of updating without the problems that seem to crop up so often using portupgrade. Just my 2ยข. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Re[2]: portupgrade stale dependencies
On 10/28/05, Gerard Seibert [EMAIL PROTECTED] wrote: Personally, I feel that portmanager does a much better job of updating without the problems that seem to crop up so often using portupgrade. I've always been scared off by the comparatively young age of portmanager. Besides, portupgrade comes with a set of useful tools, like cvsweb browser. But the fat ruby dependency and some other things make me want something else. I'd be glad to see a perl-based ports management system. Maybe I'll write one some day :-) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portupgrade stale dependencies
On Friday 28 October 2005 00:25, Andrew P. wrote: On 10/28/05, Michael C. Shultz [EMAIL PROTECTED] wrote: On Thursday 27 October 2005 18:49, Eric F Crist wrote: On Oct 27, 2005, at 8:32 PM, John DeStefano wrote: On 10/27/05, Andrew P. [EMAIL PROTECTED] wrote: On 10/27/05, John DeStefano [EMAIL PROTECTED] wrote: After clearing out the ports, updating ports (with portsnap) and source, and rebuilding the system and kernel... it seemed the ultimate problem was actually a dependency of the package to apache1.3. After I ran 'pkgdb -F' and fixed this dependency to point to apache2.1, but I still had trouble installing ports. At this point, what usually works for me is to: #cd /usr rm -rf ./ports #mkdir ./ports cvsup /root/ports-supfile The above will delete your ENTIRE ports tree, provided it's kept in / usr/ports and as long as you use cvsup (and your ports supfile is / root/ports-supfile as mine is). When a whole bunch of ports stop working, I find this is the easiest thing to do. The other thing I do is run a cron job every week that updates, via cvsup, the ports tree. About once a year I perform the above, mostly to clean out the crap. Re-downloading your entire ports tree will be quicker if you don't use the ports-all tag and actually define which port segments you are interested in. For example, there's no real reason to download all the x11/kde/gnome crap if you're doing this on a headless server that isn't going to serve X. HTH Replacing /usr/ports won't fix his problems, they reside in /var/db/pkg. I may be a bit biased but I reaaly think John D. should try running portmanager -u (ports/sysutils/portmanager). Stale dependencies is a non issue for portmanager. -Mike I don't think that stale dependencies are an issue for portupgrade as well, just add -O to the command- line. From portupgrade's man page: -O --omit-check Omit sanity checks for dependencies. By default, portupgrade checks if all the packages to upgrade have consistent dependencies, though it takes extra time to calculate dependencies. If you are sure you have run ``pkgdb -F'' in advance, you can specify this option to omit the sanity checks. Seems to be a caveat to the -O command. What happens if pkgdb -F isn't run first? -Mike ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portupgrade stale dependencies
On Friday 28 October 2005 05:53, John DeStefano wrote: On 10/27/05, Michael C. Shultz [EMAIL PROTECTED] wrote: On Thursday 27 October 2005 18:49, Eric F Crist wrote: On Oct 27, 2005, at 8:32 PM, John DeStefano wrote: On 10/27/05, Andrew P. [EMAIL PROTECTED] wrote: On 10/27/05, John DeStefano [EMAIL PROTECTED] wrote: After clearing out the ports, updating ports (with portsnap) and source, and rebuilding the system and kernel... it seemed the ultimate problem was actually a dependency of the package to apache1.3. After I ran 'pkgdb -F' and fixed this dependency to point to apache2.1, but I still had trouble installing ports. At this point, what usually works for me is to: #cd /usr rm -rf ./ports #mkdir ./ports cvsup /root/ports-supfile The above will delete your ENTIRE ports tree, provided it's kept in / usr/ports and as long as you use cvsup (and your ports supfile is / root/ports-supfile as mine is). When a whole bunch of ports stop working, I find this is the easiest thing to do. The other thing I do is run a cron job every week that updates, via cvsup, the ports tree. About once a year I perform the above, mostly to clean out the crap. Re-downloading your entire ports tree will be quicker if you don't use the ports-all tag and actually define which port segments you are interested in. For example, there's no real reason to download all the x11/kde/gnome crap if you're doing this on a headless server that isn't going to serve X. HTH Replacing /usr/ports won't fix his problems, they reside in /var/db/pkg. I may be a bit biased but I reaaly think John D. should try running portmanager -u (ports/sysutils/portmanager). Stale dependencies is a non issue for portmanager. -Mike Biased indeed. ;) I tried it, and it did work for some ports, but not all. Here's the report output of a second run-through: status report finished percentDone-=16 = 100 - ( 100 * ( QTY_outOfDatePortsDb-=10 / TOTAL_outOfDatePortsDb-=12 ) ) checkForOldDepencies 0.3.0_0 skip: apsfilter-7.2.6 has a dependency acroread-5.08 that needs to be updated first upgrade 0.3.0_0 info: ignoring scrollkeeper-0.3.12_1,1, reason: failed during (2) make upgrade 0.3.0_0 info: ignoring cups-pstoraster-7.07, reason: failed during (2) make checkForOldDepencies 0.3.0_0 skip: eog2-2.2.1 has a dependency scrollkeeper-0.3.12_1,1 that needs to be updated first checkForOldDepencies 0.3.0_0 skip: apsfilter-7.2.6 has a dependency acroread-5.08 that needs to be updated first upgrade 0.3.0_0 info: ignoring emacs-21.3, reason: failed during (2) make upgrade 0.3.0_0 info: ignoring gconf-editor-2.4.0,1, reason: performed (6) emergancy restore upgrade 0.3.0_0 info: ignoring apache-2.0.48, reason: failed during (2) make checkForOldDepencies 0.3.0_0 skip: gnomeuserdocs2-2.0.6_1 has a dependency scrollkeeper-0.3.12_1,1 that needs to be updated first upgrade 0.3.0_0 info: ignoring acroread-5.08, reason: marked FORBIDDEN update of ports collection complete with either some errors, ignored ports or both A few suggestions: If you want to update acroread-5.08 you should do that one manually because it is FORBIDDEN, there is probably an overide switch, I don't know what it is. You can also just comment out the FORBIDDEN line in acroread-5.08's Makefile. Note ports are marked FORBIDDEN because they have security problems I'm not sure about cups-pstoraster-7.07 builds but scrollkeeper-0.3.14_1,1 builds on my system, try pkg_delete -f scrollkeeper-0.3.12_1,1 then rerun portmanager -u and hopefully you will be down to just cups-pstoraster-7.07 failing. You'll have to figure out its problem on your own or contact the maintainer for help. -Mike ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portupgrade stale dependencies
On 10/27/05, Michael C. Shultz [EMAIL PROTECTED] wrote: On Thursday 27 October 2005 18:49, Eric F Crist wrote: On Oct 27, 2005, at 8:32 PM, John DeStefano wrote: On 10/27/05, Andrew P. [EMAIL PROTECTED] wrote: On 10/27/05, John DeStefano [EMAIL PROTECTED] wrote: After clearing out the ports, updating ports (with portsnap) and source, and rebuilding the system and kernel... it seemed the ultimate problem was actually a dependency of the package to apache1.3. After I ran 'pkgdb -F' and fixed this dependency to point to apache2.1, but I still had trouble installing ports. At this point, what usually works for me is to: #cd /usr rm -rf ./ports #mkdir ./ports cvsup /root/ports-supfile The above will delete your ENTIRE ports tree, provided it's kept in / usr/ports and as long as you use cvsup (and your ports supfile is / root/ports-supfile as mine is). When a whole bunch of ports stop working, I find this is the easiest thing to do. The other thing I do is run a cron job every week that updates, via cvsup, the ports tree. About once a year I perform the above, mostly to clean out the crap. Re-downloading your entire ports tree will be quicker if you don't use the ports-all tag and actually define which port segments you are interested in. For example, there's no real reason to download all the x11/kde/gnome crap if you're doing this on a headless server that isn't going to serve X. HTH Replacing /usr/ports won't fix his problems, they reside in /var/db/pkg. I may be a bit biased but I reaaly think John D. should try running portmanager -u (ports/sysutils/portmanager). Stale dependencies is a non issue for portmanager. -Mike Biased indeed. ;) I tried it, and it did work for some ports, but not all. Here's the report output of a second run-through: status report finished percentDone-=16 = 100 - ( 100 * ( QTY_outOfDatePortsDb-=10 / TOTAL_outOfDatePortsDb-=12 ) ) checkForOldDepencies 0.3.0_0 skip: apsfilter-7.2.6 has a dependency acroread-5.08 that needs to be updated first upgrade 0.3.0_0 info: ignoring scrollkeeper-0.3.12_1,1, reason: failed during (2) make upgrade 0.3.0_0 info: ignoring cups-pstoraster-7.07, reason: failed during (2) make checkForOldDepencies 0.3.0_0 skip: eog2-2.2.1 has a dependency scrollkeeper-0.3.12_1,1 that needs to be updated first checkForOldDepencies 0.3.0_0 skip: apsfilter-7.2.6 has a dependency acroread-5.08 that needs to be updated first upgrade 0.3.0_0 info: ignoring emacs-21.3, reason: failed during (2) make upgrade 0.3.0_0 info: ignoring gconf-editor-2.4.0,1, reason: performed (6) emergancy restore upgrade 0.3.0_0 info: ignoring apache-2.0.48, reason: failed during (2) make checkForOldDepencies 0.3.0_0 skip: gnomeuserdocs2-2.0.6_1 has a dependency scrollkeeper-0.3.12_1,1 that needs to be updated first upgrade 0.3.0_0 info: ignoring acroread-5.08, reason: marked FORBIDDEN update of ports collection complete with either some errors, ignored ports or both ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portupgrade stale dependencies
On 10/28/05, Michael C. Shultz [EMAIL PROTECTED] wrote: On Friday 28 October 2005 05:53, John DeStefano wrote: On 10/27/05, Michael C. Shultz [EMAIL PROTECTED] wrote: On Thursday 27 October 2005 18:49, Eric F Crist wrote: On Oct 27, 2005, at 8:32 PM, John DeStefano wrote: On 10/27/05, Andrew P. [EMAIL PROTECTED] wrote: On 10/27/05, John DeStefano [EMAIL PROTECTED] wrote: After clearing out the ports, updating ports (with portsnap) and source, and rebuilding the system and kernel... it seemed the ultimate problem was actually a dependency of the package to apache1.3. After I ran 'pkgdb -F' and fixed this dependency to point to apache2.1, but I still had trouble installing ports. At this point, what usually works for me is to: #cd /usr rm -rf ./ports #mkdir ./ports cvsup /root/ports-supfile The above will delete your ENTIRE ports tree, provided it's kept in / usr/ports and as long as you use cvsup (and your ports supfile is / root/ports-supfile as mine is). When a whole bunch of ports stop working, I find this is the easiest thing to do. The other thing I do is run a cron job every week that updates, via cvsup, the ports tree. About once a year I perform the above, mostly to clean out the crap. Re-downloading your entire ports tree will be quicker if you don't use the ports-all tag and actually define which port segments you are interested in. For example, there's no real reason to download all the x11/kde/gnome crap if you're doing this on a headless server that isn't going to serve X. HTH Replacing /usr/ports won't fix his problems, they reside in /var/db/pkg. I may be a bit biased but I reaaly think John D. should try running portmanager -u (ports/sysutils/portmanager). Stale dependencies is a non issue for portmanager. -Mike Biased indeed. ;) I tried it, and it did work for some ports, but not all. Here's the report output of a second run-through: status report finished percentDone-=16 = 100 - ( 100 * ( QTY_outOfDatePortsDb-=10 / TOTAL_outOfDatePortsDb-=12 ) ) checkForOldDepencies 0.3.0_0 skip: apsfilter-7.2.6 has a dependency acroread-5.08 that needs to be updated first upgrade 0.3.0_0 info: ignoring scrollkeeper-0.3.12_1,1, reason: failed during (2) make upgrade 0.3.0_0 info: ignoring cups-pstoraster-7.07, reason: failed during (2) make checkForOldDepencies 0.3.0_0 skip: eog2-2.2.1 has a dependency scrollkeeper-0.3.12_1,1 that needs to be updated first checkForOldDepencies 0.3.0_0 skip: apsfilter-7.2.6 has a dependency acroread-5.08 that needs to be updated first upgrade 0.3.0_0 info: ignoring emacs-21.3, reason: failed during (2) make upgrade 0.3.0_0 info: ignoring gconf-editor-2.4.0,1, reason: performed (6) emergancy restore upgrade 0.3.0_0 info: ignoring apache-2.0.48, reason: failed during (2) make checkForOldDepencies 0.3.0_0 skip: gnomeuserdocs2-2.0.6_1 has a dependency scrollkeeper-0.3.12_1,1 that needs to be updated first upgrade 0.3.0_0 info: ignoring acroread-5.08, reason: marked FORBIDDEN update of ports collection complete with either some errors, ignored ports or both A few suggestions: If you want to update acroread-5.08 you should do that one manually because it is FORBIDDEN, there is probably an overide switch, I don't know what it is. You can also just comment out the FORBIDDEN line in acroread-5.08's Makefile. Note ports are marked FORBIDDEN because they have security problems I'm not sure about cups-pstoraster-7.07 builds but scrollkeeper-0.3.14_1,1 builds on my system, try pkg_delete -f scrollkeeper-0.3.12_1,1 then rerun portmanager -u and hopefully you will be down to just cups-pstoraster-7.07 failing. You'll have to figure out its problem on your own or contact the maintainer for help. -Mike After tons of manual deinstalling, upgrading, tinkering, etc. (I wanted to script everything I did, but at this point the audit trail would have been about a GB in size), I am down to a single outdated port: status report finished percentDone-=0 = 100 - ( 100 * ( QTY_outOfDatePortsDb-=1 / TOTAL_outOfDatePortsDb-=1 ) ) upgrade 0.3.0_0 info: ignoring apache-2.0.48, reason: failed during (2) make update of ports collection complete with either some errors, ignored ports or both Unfortunately, this is the most crucial of all, and ironically the one about which I've been asking since the beginning. As I mentioned earlier, upgrading this port bails consistently with a C callout to PEM_F_DEF_CALLBACK. I'd really like to get this port updated, not only
Re: portupgrade stale dependencies
status report finished == == percentDone-=0 = 100 - ( 100 * ( QTY_outOfDatePortsDb-=1 / TOTAL_outOfDatePortsDb-=1 ) ) upgrade 0.3.0_0 info: ignoring apache-2.0.48, reason: failed during (2) make -- -- update of ports collection complete with either some errors, ignored ports or both Unfortunately, this is the most crucial of all, and ironically the one about which I've been asking since the beginning. As I mentioned earlier, upgrading this port bails consistently with a C callout to PEM_F_DEF_CALLBACK. I'd really like to get this port updated, not only to finally complete this insane goose chase of updating, but because I know that apache-2.0.48 is chock full of vulerabilities. cd /usr/ports/www/apache20 make deinstall make clean make reinstall See what happens. - Eric F Crist Secure Computing Networks http://www.secure-computing.net ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Fwd: Re: portupgrade stale dependencies
-- Forwarded Message -- Subject: Re: portupgrade stale dependencies Date: Friday 28 October 2005 15:02 From: Michael C. Shultz [EMAIL PROTECTED] To: John DeStefano [EMAIL PROTECTED] On Friday 28 October 2005 13:29, John DeStefano wrote: On 10/28/05, Michael C. Shultz [EMAIL PROTECTED] wrote: On Friday 28 October 2005 05:53, John DeStefano wrote: On 10/27/05, Michael C. Shultz [EMAIL PROTECTED] wrote: On Thursday 27 October 2005 18:49, Eric F Crist wrote: On Oct 27, 2005, at 8:32 PM, John DeStefano wrote: On 10/27/05, Andrew P. [EMAIL PROTECTED] wrote: On 10/27/05, John DeStefano [EMAIL PROTECTED] wrote: After clearing out the ports, updating ports (with portsnap) and source, and rebuilding the system and kernel... it seemed the ultimate problem was actually a dependency of the package to apache1.3. After I ran 'pkgdb -F' and fixed this dependency to point to apache2.1, but I still had trouble installing ports. At this point, what usually works for me is to: #cd /usr rm -rf ./ports #mkdir ./ports cvsup /root/ports-supfile The above will delete your ENTIRE ports tree, provided it's kept in / usr/ports and as long as you use cvsup (and your ports supfile is / root/ports-supfile as mine is). When a whole bunch of ports stop working, I find this is the easiest thing to do. The other thing I do is run a cron job every week that updates, via cvsup, the ports tree. About once a year I perform the above, mostly to clean out the crap. Re-downloading your entire ports tree will be quicker if you don't use the ports-all tag and actually define which port segments you are interested in. For example, there's no real reason to download all the x11/kde/gnome crap if you're doing this on a headless server that isn't going to serve X. HTH Replacing /usr/ports won't fix his problems, they reside in /var/db/pkg. I may be a bit biased but I reaaly think John D. should try running portmanager -u (ports/sysutils/portmanager). Stale dependencies is a non issue for portmanager. -Mike Biased indeed. ;) I tried it, and it did work for some ports, but not all. Here's the report output of a second run-through: status report finished === = percentDone-=16 = 100 - ( 100 * ( QTY_outOfDatePortsDb-=10 / TOTAL_outOfDatePortsDb-=12 ) ) checkForOldDepencies 0.3.0_0 skip: apsfilter-7.2.6 has a dependency acroread-5.08 that needs to be updated first upgrade 0.3.0_0 info: ignoring scrollkeeper-0.3.12_1,1, reason: failed during (2) make upgrade 0.3.0_0 info: ignoring cups-pstoraster-7.07, reason: failed during (2) make checkForOldDepencies 0.3.0_0 skip: eog2-2.2.1 has a dependency scrollkeeper-0.3.12_1,1 that needs to be updated first checkForOldDepencies 0.3.0_0 skip: apsfilter-7.2.6 has a dependency acroread-5.08 that needs to be updated first upgrade 0.3.0_0 info: ignoring emacs-21.3, reason: failed during (2) make upgrade 0.3.0_0 info: ignoring gconf-editor-2.4.0,1, reason: performed (6) emergancy restore upgrade 0.3.0_0 info: ignoring apache-2.0.48, reason: failed during (2) make checkForOldDepencies 0.3.0_0 skip: gnomeuserdocs2-2.0.6_1 has a dependency scrollkeeper-0.3.12_1,1 that needs to be updated first upgrade 0.3.0_0 info: ignoring acroread-5.08, reason: marked FORBIDDEN --- - update of ports collection complete with either some errors, ignored ports or both A few suggestions: If you want to update acroread-5.08 you should do that one manually because it is FORBIDDEN, there is probably an overide switch, I don't know what it is. You can also just comment out the FORBIDDEN line in acroread-5.08's Makefile. Note ports are marked FORBIDDEN because they have security problems I'm not sure about cups-pstoraster-7.07 builds but scrollkeeper-0.3.14_1,1 builds on my system, try pkg_delete -f scrollkeeper-0.3.12_1,1 then rerun portmanager -u and hopefully you will be down to just cups-pstoraster-7.07 failing. You'll have to figure out its problem on your own or contact the maintainer for help. -Mike After tons of manual deinstalling, upgrading, tinkering, etc. (I wanted to script everything I did, but at this point the audit trail would have been about a GB in size), I am down to a single outdated port: status report finished percentDone-=0 = 100 - ( 100 * ( QTY_outOfDatePortsDb-=1 / TOTAL_outOfDatePortsDb-=1 ) ) upgrade 0.3.0_0 info: ignoring apache-2.0.48, reason: failed during (2) make
Re: portupgrade stale dependencies
On 10/28/05, Eric F Crist [EMAIL PROTECTED] wrote: status report finished == == percentDone-=0 = 100 - ( 100 * ( QTY_outOfDatePortsDb-=1 / TOTAL_outOfDatePortsDb-=1 ) ) upgrade 0.3.0_0 info: ignoring apache-2.0.48, reason: failed during (2) make -- -- update of ports collection complete with either some errors, ignored ports or both Unfortunately, this is the most crucial of all, and ironically the one about which I've been asking since the beginning. As I mentioned earlier, upgrading this port bails consistently with a C callout to PEM_F_DEF_CALLBACK. I'd really like to get this port updated, not only to finally complete this insane goose chase of updating, but because I know that apache-2.0.48 is chock full of vulerabilities. cd /usr/ports/www/apache20 make deinstall make clean make reinstall See what happens. Talk about strange: # cd /usr/ports/www/apache20/ # make deinstall === Deinstalling for www/apache20 === apache not installed, skipping # make -V PKGNAME apache-2.0.55 # pkg_info | grep apache apache-2.0.48 Version 2 of the extremely popular Apache http server # apachectl -v Server version: Apache/2.0.48 Server built: Nov 19 2003 22:44:21 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portupgrade stale dependencies
On Friday 28 October 2005 17:31, John DeStefano wrote: On 10/28/05, Eric F Crist [EMAIL PROTECTED] wrote: status report finished == == percentDone-=0 = 100 - ( 100 * ( QTY_outOfDatePortsDb-=1 / TOTAL_outOfDatePortsDb-=1 ) ) upgrade 0.3.0_0 info: ignoring apache-2.0.48, reason: failed during (2) make -- -- update of ports collection complete with either some errors, ignored ports or both Unfortunately, this is the most crucial of all, and ironically the one about which I've been asking since the beginning. As I mentioned earlier, upgrading this port bails consistently with a C callout to PEM_F_DEF_CALLBACK. I'd really like to get this port updated, not only to finally complete this insane goose chase of updating, but because I know that apache-2.0.48 is chock full of vulerabilities. cd /usr/ports/www/apache20 make deinstall make clean make reinstall See what happens. Talk about strange: # cd /usr/ports/www/apache20/ # make deinstall === Deinstalling for www/apache20 === apache not installed, skipping # make -V PKGNAME apache-2.0.55 # pkg_info | grep apache apache-2.0.48 Version 2 of the extremely popular Apache http server # apachectl -v Server version: Apache/2.0.48 Server built: Nov 19 2003 22:44:21 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] Try ls /var/db/pkg/a* any apache versions in there? -Mike ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portupgrade stale dependencies
On Friday 28 October 2005 19:51, John DeStefano wrote: On 10/28/05, Michael C. Shultz [EMAIL PROTECTED] wrote: On Friday 28 October 2005 17:31, John DeStefano wrote: On 10/28/05, Eric F Crist [EMAIL PROTECTED] wrote: status report finished === === == percentDone-=0 = 100 - ( 100 * ( QTY_outOfDatePortsDb-=1 / TOTAL_outOfDatePortsDb-=1 ) ) upgrade 0.3.0_0 info: ignoring apache-2.0.48, reason: failed during (2) make --- --- -- update of ports collection complete with either some errors, ignored ports or both Unfortunately, this is the most crucial of all, and ironically the one about which I've been asking since the beginning. As I mentioned earlier, upgrading this port bails consistently with a C callout to PEM_F_DEF_CALLBACK. I'd really like to get this port updated, not only to finally complete this insane goose chase of updating, but because I know that apache-2.0.48 is chock full of vulerabilities. cd /usr/ports/www/apache20 make deinstall make clean make reinstall See what happens. Talk about strange: # cd /usr/ports/www/apache20/ # make deinstall === Deinstalling for www/apache20 === apache not installed, skipping # make -V PKGNAME apache-2.0.55 # pkg_info | grep apache apache-2.0.48 Version 2 of the extremely popular Apache http server # apachectl -v Server version: Apache/2.0.48 Server built: Nov 19 2003 22:44:21 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] Try ls /var/db/pkg/a* any apache versions in there? -Mike Yep: it was 2.0.48 I ended up deinstalling that apache installation (which I was not keen on doing), and installing the apache20 port (which was the same version (2.0.55) as the apache2 port ?), and, thankfully, it's working fine. I'm also now able to run both 'pkgdb -F'and 'portsdb -Uu' without ANY errors (except for a few 'Duplicate INDEX entry' warnings). Needless to say, this process wasn't much fun. What can I do to keep this from happening again? What can/can't I safely include in cron to automate database and index maintenance? Thanks to all. Pardon my bias agan ;) but I'd recommend only updating with portmanager. From cron I'd just run a cvsupdate and portmanager -s /root/portmanager.log. Review the log from time toi time and when you see something that should be updated run portmanager -u manually. Some ports do not do well being built from cron so will save you much trouble to do the updates manually. As far as the INDEX goes, portmanager doesn't require it, but other utilies do so maybe add a make fetch index to cron as well. Congradulations on getting everything fixed BTW. -Mike ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portupgrade stale dependencies
On 10/28/05, Michael C. Shultz [EMAIL PROTECTED] wrote: On Friday 28 October 2005 17:31, John DeStefano wrote: On 10/28/05, Eric F Crist [EMAIL PROTECTED] wrote: status report finished == == percentDone-=0 = 100 - ( 100 * ( QTY_outOfDatePortsDb-=1 / TOTAL_outOfDatePortsDb-=1 ) ) upgrade 0.3.0_0 info: ignoring apache-2.0.48, reason: failed during (2) make -- -- update of ports collection complete with either some errors, ignored ports or both Unfortunately, this is the most crucial of all, and ironically the one about which I've been asking since the beginning. As I mentioned earlier, upgrading this port bails consistently with a C callout to PEM_F_DEF_CALLBACK. I'd really like to get this port updated, not only to finally complete this insane goose chase of updating, but because I know that apache-2.0.48 is chock full of vulerabilities. cd /usr/ports/www/apache20 make deinstall make clean make reinstall See what happens. Talk about strange: # cd /usr/ports/www/apache20/ # make deinstall === Deinstalling for www/apache20 === apache not installed, skipping # make -V PKGNAME apache-2.0.55 # pkg_info | grep apache apache-2.0.48 Version 2 of the extremely popular Apache http server # apachectl -v Server version: Apache/2.0.48 Server built: Nov 19 2003 22:44:21 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] Try ls /var/db/pkg/a* any apache versions in there? -Mike Yep: it was 2.0.48 I ended up deinstalling that apache installation (which I was not keen on doing), and installing the apache20 port (which was the same version (2.0.55) as the apache2 port ?), and, thankfully, it's working fine. I'm also now able to run both 'pkgdb -F'and 'portsdb -Uu' without ANY errors (except for a few 'Duplicate INDEX entry' warnings). Needless to say, this process wasn't much fun. What can I do to keep this from happening again? What can/can't I safely include in cron to automate database and index maintenance? Thanks to all. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portupgrade stale dependencies
On 10/27/05, John DeStefano [EMAIL PROTECTED] wrote: ...snip... After clearing out the ports, updating ports (with portsnap) and source, and rebuilding the system and kernel... it seemed the ultimate problem was actually a dependency of the package to apache1.3. After I ran 'pkgdb -F' and fixed this dependency to point to apache2.1, but I still had trouble installing ports. 'portsdb -Uu' would not run, so I ran 'make fetchindex' and 'portupdate -a'. From what I've read, this _should_ create an index and update all out-of-date ports and their dependencies, but it never has worked for me. I just tried this combination again, and it (again) punts during portupdate. This time, 38 ports were skipped and 7 failed, the first failure being a strange compiler error in updating from apache-2.0.48. I've been fighting with ports for long enough now to have become a bit frustrated with them. If you have any thoughts or suggestions on how to troubleshoot them, please pass them on. Thanks, ~John Do not fix dependencies if you're not sure that they are really broken. Don't use apache21 unless 2.0 is absolutely inappropriate. The proper way to change dependencies from apache1 to apache2 is to add WITH_APACHE2=true to /etc/make.conf (or to /usr/local/etc/pkgtools.conf, but that's an advanced topic). If you have portsdb utility, don't use make fetchindex, just add -F to portsdb: portsdb -uUF will work fine. You cann add -k to portupgrade, so that it doesn't skip ports (but it won't fix the failed ones). John, you'll have to spend a few hours reading ports documentation before you find them really great (which they really are). ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portupgrade stale dependencies
On 10/27/05, Andrew P. [EMAIL PROTECTED] wrote: On 10/27/05, John DeStefano [EMAIL PROTECTED] wrote: After clearing out the ports, updating ports (with portsnap) and source, and rebuilding the system and kernel... it seemed the ultimate problem was actually a dependency of the package to apache1.3. After I ran 'pkgdb -F' and fixed this dependency to point to apache2.1, but I still had trouble installing ports. 'portsdb -Uu' would not run, so I ran 'make fetchindex' and 'portupdate -a'. From what I've read, this _should_ create an index and update all out-of-date ports and their dependencies, but it never has worked for me. I just tried this combination again, and it (again) punts during portupdate. This time, 38 ports were skipped and 7 failed, the first failure being a strange compiler error in updating from apache-2.0.48. I've been fighting with ports for long enough now to have become a bit frustrated with them. If you have any thoughts or suggestions on how to troubleshoot them, please pass them on. Thanks, ~John Do not fix dependencies if you're not sure that they are really broken. Don't use apache21 unless 2.0 is absolutely inappropriate. The proper way to change dependencies from apache1 to apache2 is to add WITH_APACHE2=true to /etc/make.conf (or to /usr/local/etc/pkgtools.conf, but that's an advanced topic). I wasn't really looking to upgrade to apache21, just to update my version (2.0.48) to any more current port, since other ports keep barking about it being out-of-date. I added the WITH_APACHE2=true parameter, but when I try to upgrade my apache port, it seems to still be looking to the wrong version: ...Upgrading 'apache-2.0.48' to 'apache-2.1.4' (www/apache21) This process attempts to build and then consistently fails with the same error, which seems to my untrained eye like a C function error in httpd: ssl_engine_pphrase.c: In function `ssl_pphrase_Handle_CB': ssl_engine_pphrase.c:684: error: `PEM_F_DEF_CALLBACK' undeclared (first use in this function) ssl_engine_pphrase.c:684: error: (Each undeclared identifier is reported only once ssl_engine_pphrase.c:684: error: for each function it appears in.) *** Error code 1 Stop in /usr/ports/www/apache21/work/httpd-2.1.4-alpha/modules/ssl. *** Error code 1 Stop in /usr/ports/www/apache21/work/httpd-2.1.4-alpha/modules/ssl. *** Error code 1 Stop in /usr/ports/www/apache21/work/httpd-2.1.4-alpha/modules. *** Error code 1 Stop in /usr/ports/www/apache21/work/httpd-2.1.4-alpha. *** Error code 1 Stop in /usr/ports/www/apache21/work/httpd-2.1.4-alpha. *** Error code 1 Stop in /usr/ports/www/apache21. ** Command failed [exit code 1]: /usr/bin/script -qa /tmp/portupgrade38050.3 make ** Fix the problem and try again. Apparently, this is an OpenSSL-related bug, and there's a patch availavble for it somewhere ? Is there a way to fix this without applying a patch? If you have portsdb utility, don't use make fetchindex, just add -F to portsdb: portsdb -uUF will work fine. portsdb -uU wasn't working for me for a while, but I finally got it going last night. Kris maintained that I should use make fetchindex instead of portsdb -uU before running portupgrade -a, at least until my package installation dependencies were in better condition, at which time I could resume using portsdb -uU. Problem is, portupgrade -a still isn't working to update all installed packages (most, but not all), regardless of whether it is preceded by portsdb -uU or portupgrade -a. You cann add -k to portupgrade, so that it doesn't skip ports (but it won't fix the failed ones). John, you'll have to spend a few hours reading ports documentation before you find them really great (which they really are). I have no problem with reading as much documentation as I can find. Aside from the handbook (Chapter 4, which is a nice overview) and man pages (which are great for quick and complete reference), what else would you recommend for gaining a more detailed understanding? And I do already agree that the port system is great, even with all the trouble I'm having. Thanks. ~John ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portupgrade stale dependencies
On Oct 27, 2005, at 8:32 PM, John DeStefano wrote: On 10/27/05, Andrew P. [EMAIL PROTECTED] wrote: On 10/27/05, John DeStefano [EMAIL PROTECTED] wrote: After clearing out the ports, updating ports (with portsnap) and source, and rebuilding the system and kernel... it seemed the ultimate problem was actually a dependency of the package to apache1.3. After I ran 'pkgdb -F' and fixed this dependency to point to apache2.1, but I still had trouble installing ports. At this point, what usually works for me is to: #cd /usr rm -rf ./ports #mkdir ./ports cvsup /root/ports-supfile The above will delete your ENTIRE ports tree, provided it's kept in / usr/ports and as long as you use cvsup (and your ports supfile is / root/ports-supfile as mine is). When a whole bunch of ports stop working, I find this is the easiest thing to do. The other thing I do is run a cron job every week that updates, via cvsup, the ports tree. About once a year I perform the above, mostly to clean out the crap. Re-downloading your entire ports tree will be quicker if you don't use the ports-all tag and actually define which port segments you are interested in. For example, there's no real reason to download all the x11/kde/gnome crap if you're doing this on a headless server that isn't going to serve X. HTH ___ Eric F Crist I am so smart, S.M.R.T! Secure Computing Networks -Homer J Simpson ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portupgrade stale dependencies
On Thursday 27 October 2005 18:49, Eric F Crist wrote: On Oct 27, 2005, at 8:32 PM, John DeStefano wrote: On 10/27/05, Andrew P. [EMAIL PROTECTED] wrote: On 10/27/05, John DeStefano [EMAIL PROTECTED] wrote: After clearing out the ports, updating ports (with portsnap) and source, and rebuilding the system and kernel... it seemed the ultimate problem was actually a dependency of the package to apache1.3. After I ran 'pkgdb -F' and fixed this dependency to point to apache2.1, but I still had trouble installing ports. At this point, what usually works for me is to: #cd /usr rm -rf ./ports #mkdir ./ports cvsup /root/ports-supfile The above will delete your ENTIRE ports tree, provided it's kept in / usr/ports and as long as you use cvsup (and your ports supfile is / root/ports-supfile as mine is). When a whole bunch of ports stop working, I find this is the easiest thing to do. The other thing I do is run a cron job every week that updates, via cvsup, the ports tree. About once a year I perform the above, mostly to clean out the crap. Re-downloading your entire ports tree will be quicker if you don't use the ports-all tag and actually define which port segments you are interested in. For example, there's no real reason to download all the x11/kde/gnome crap if you're doing this on a headless server that isn't going to serve X. HTH Replacing /usr/ports won't fix his problems, they reside in /var/db/pkg. I may be a bit biased but I reaaly think John D. should try running portmanager -u (ports/sysutils/portmanager). Stale dependencies is a non issue for portmanager. -Mike ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portupgrade stale dependencies
On 10/18/05, John DeStefano [EMAIL PROTECTED] wrote: On 10/15/05, Andrew P. [EMAIL PROTECTED] wrote: On 10/16/05, John DeStefano [EMAIL PROTECTED] wrote: I'm trying to use portupgrade to update my installed ports. I ran into trouble with dependencies with ImageMagick and xorg-libraries, and I then followed the suggestion in UPDATING to delete XFree86 the imake-4 packages, and install the full xorg port. After all that, I got more dependency errors: 'Stale dependency: aalib-1.4.r5_1 -- imake-4.3.0_1 -- manually run 'pkgdb -F' to fix, or specify -O to force.' 'pkgdb -O' returned an invalid option error, and 'pkgdb -o aalib-1.4.r5_1' returned 'graphics/aalib'. I then ran 'pkgdb -F' to try and fix this (and many, many other) stale dependencies, but the error I got when trying to run portupgrade afterward simply changed the stale dependency error to ' aalib-1.4.r5_1 -- XFree86-libraries-4.3.0_6'. How does one get around these dependency errors without destroying a system? Any good resources on dealing with this? I keep reading that I should just run 'pkgdb -F' but that only gets one so far. Thanks, ~John ___ If you don't have a whole free week, consider deinstalling every port on your system (with pkg_deinstall preferably), installing cvsup, updating your ports tree, installing portupgrade, and portinstalling all the ports you really need. That should only take a couple of days :-) You're not kidding... between fixing these dependencies, trying to upgrade the ports, fixing more dependencies, upgrading ports, etc. ad nausem, I'm literally on my 9th straight day (obviously I don't mean 24/7... I have a day job and something of a life) of trying to get through this process. And all this just because I wanted to install mbstring (so phpMyadmin would stop barking about it), and I needed to perform some simple updates first... Any pointers, alternatives, etc., would be appreciated. BTW, I can no longer automatically update my ports list (I mean with 'portsdb -Uu' instead of fetching a premade index) due to a chinese/acroread-chsfont failed error. I see via Google that this port was removed due to a security vulnerability, but I don't know how to remove it from my system, and UPDATING doesn't seem to mention it. Help? Thanks, ~John Either cvsup or portsnap extract should remove it. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portupgrade stale dependencies
On 10/15/05, Andrew P. [EMAIL PROTECTED] wrote: On 10/16/05, John DeStefano [EMAIL PROTECTED] wrote: I'm trying to use portupgrade to update my installed ports. I ran into trouble with dependencies with ImageMagick and xorg-libraries, and I then followed the suggestion in UPDATING to delete XFree86 the imake-4 packages, and install the full xorg port. After all that, I got more dependency errors: 'Stale dependency: aalib-1.4.r5_1 -- imake-4.3.0_1 -- manually run 'pkgdb -F' to fix, or specify -O to force.' 'pkgdb -O' returned an invalid option error, and 'pkgdb -o aalib-1.4.r5_1' returned 'graphics/aalib'. I then ran 'pkgdb -F' to try and fix this (and many, many other) stale dependencies, but the error I got when trying to run portupgrade afterward simply changed the stale dependency error to ' aalib-1.4.r5_1 -- XFree86-libraries-4.3.0_6'. How does one get around these dependency errors without destroying a system? Any good resources on dealing with this? I keep reading that I should just run 'pkgdb -F' but that only gets one so far. Thanks, ~John ___ If you don't have a whole free week, consider deinstalling every port on your system (with pkg_deinstall preferably), installing cvsup, updating your ports tree, installing portupgrade, and portinstalling all the ports you really need. That should only take a couple of days :-) You're not kidding... between fixing these dependencies, trying to upgrade the ports, fixing more dependencies, upgrading ports, etc. ad nausem, I'm literally on my 9th straight day (obviously I don't mean 24/7... I have a day job and something of a life) of trying to get through this process. And all this just because I wanted to install mbstring (so phpMyadmin would stop barking about it), and I needed to perform some simple updates first... Any pointers, alternatives, etc., would be appreciated. BTW, I can no longer automatically update my ports list (I mean with 'portsdb -Uu' instead of fetching a premade index) due to a chinese/acroread-chsfont failed error. I see via Google that this port was removed due to a security vulnerability, but I don't know how to remove it from my system, and UPDATING doesn't seem to mention it. Help? Thanks, ~John ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re[2]: portupgrade stale dependencies
On Saturday, October 15, 2005 9:21:00 PM, Andrew P. [EMAIL PROTECTED] Subject: Re: portupgrade stale dependencies Wrote these words of wisdom: On 10/16/05, John DeStefano [EMAIL PROTECTED] wrote: I'm trying to use portupgrade to update my installed ports. I ran into trouble with dependencies with ImageMagick and xorg-libraries, and I then followed the suggestion in UPDATING to delete XFree86 the imake-4 packages, and install the full xorg port. After all that, I got more dependency errors: 'Stale dependency: aalib-1.4.r5_1 -- imake-4.3.0_1 -- manually run 'pkgdb -F' to fix, or specify -O to force.' 'pkgdb -O' returned an invalid option error, and 'pkgdb -o aalib-1.4.r5_1' returned 'graphics/aalib'. I then ran 'pkgdb -F' to try and fix this (and many, many other) stale dependencies, but the error I got when trying to run portupgrade afterward simply changed the stale dependency error to ' aalib-1.4.r5_1 -- XFree86-libraries-4.3.0_6'. How does one get around these dependency errors without destroying a system? Any good resources on dealing with this? I keep reading that I should just run 'pkgdb -F' but that only gets one so far. Thanks, ~John If you don't have a whole free week, consider deinstalling every port on your system (with pkg_deinstall preferably), installing cvsup, updating your ports tree, installing portupgrade, and portinstalling all the ports you really need. That should only take a couple of days :-) * REPLY SEPARATOR * On 10/11/2005 5:29:42 PM, Gerard Replied: I certainly hope that this is not a production machine. Taking the system out of service for a few days would certainly suck. Personally, I have run into this dependency problem before, and have just learned to ignore it. Eventually, it just seems to go away. Since I started using portmanager instead of portupgrade, I have been able to just ignore these problems. IMHO, this entire dependency problem is something that needs serious work. It would seem that there has to be a better way to keep these dependencies synchronized without user intervention. Just my 2ยข. -- Gerard Seibert [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
portupgrade stale dependencies
I'm trying to use portupgrade to update my installed ports. I ran into trouble with dependencies with ImageMagick and xorg-libraries, and I then followed the suggestion in UPDATING to delete XFree86 the imake-4 packages, and install the full xorg port. After all that, I got more dependency errors: 'Stale dependency: aalib-1.4.r5_1 -- imake-4.3.0_1 -- manually run 'pkgdb -F' to fix, or specify -O to force.' 'pkgdb -O' returned an invalid option error, and 'pkgdb -o aalib-1.4.r5_1' returned 'graphics/aalib'. I then ran 'pkgdb -F' to try and fix this (and many, many other) stale dependencies, but the error I got when trying to run portupgrade afterward simply changed the stale dependency error to ' aalib-1.4.r5_1 -- XFree86-libraries-4.3.0_6'. How does one get around these dependency errors without destroying a system? Any good resources on dealing with this? I keep reading that I should just run 'pkgdb -F' but that only gets one so far. Thanks, ~John ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portupgrade stale dependencies
On 10/16/05, John DeStefano [EMAIL PROTECTED] wrote: I'm trying to use portupgrade to update my installed ports. I ran into trouble with dependencies with ImageMagick and xorg-libraries, and I then followed the suggestion in UPDATING to delete XFree86 the imake-4 packages, and install the full xorg port. After all that, I got more dependency errors: 'Stale dependency: aalib-1.4.r5_1 -- imake-4.3.0_1 -- manually run 'pkgdb -F' to fix, or specify -O to force.' 'pkgdb -O' returned an invalid option error, and 'pkgdb -o aalib-1.4.r5_1' returned 'graphics/aalib'. I then ran 'pkgdb -F' to try and fix this (and many, many other) stale dependencies, but the error I got when trying to run portupgrade afterward simply changed the stale dependency error to ' aalib-1.4.r5_1 -- XFree86-libraries-4.3.0_6'. How does one get around these dependency errors without destroying a system? Any good resources on dealing with this? I keep reading that I should just run 'pkgdb -F' but that only gets one so far. Thanks, ~John ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] If you don't have a whole free week, consider deinstalling every port on your system (with pkg_deinstall preferably), installing cvsup, updating your ports tree, installing portupgrade, and portinstalling all the ports you really need. That should only take a couple of days :-) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: stale dependencies
Mark Withers wrote: Hello everyone! I've been using FBSD for a few years now, but am not sure as to what a 'stale dependency' is... I am receiving an error message with ymessenger pkg that it has stale dependencies and to use 'pkgdb -F' to fix or -O to force. I'm a bit inexperienced when it comes to repairing the package db and would appreciate any pointers you can give. http://www.onlamp.com/pub/a/bsd/2001/11/29/Big_Scary_Daemons.html Pretty good explanation by Michael Lucas of Absolute BSD fame KDK ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
stale dependencies
Hello everyone! I've been using FBSD for a few years now, but am not sure as to what a 'stale dependency' is... I am receiving an error message with ymessenger pkg that it has stale dependencies and to use 'pkgdb -F' to fix or -O to force. I'm a bit inexperienced when it comes to repairing the package db and would appreciate any pointers you can give. Thanks for listening... Mark ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: stale dependencies
On Saturday 21 August 2004 2:22 am, Mark Withers wrote: Hello everyone! I've been using FBSD for a few years now, but am not sure as to what a 'stale dependency' is... I am receiving an error message with ymessenger pkg that it has stale dependencies and to use 'pkgdb -F' to fix or -O to force. I'm a bit inexperienced when it comes to repairing the package db and would appreciate any pointers you can give. Thanks for listening... Mark Stale dependency means portupgrade doesn't recognize the dependency port used to build the listed port. It wants you to use pkgdb -F so it can force the dependency to be something portupgrade recognizes. Though your listed port was built with a stale (out of date) dependency port, portupgrade wants to change so that it looks like the listed port was built with a current up to date dependency. A better approach is to rebuild the port with newer, up to date dependency ports that are not stale. I suggest you get a current cvsup then update your port collection with sysutils/portmanager, it will rebuild your ports with only up to date dependencies. -Mike ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
How to properly handle stale dependencies with pkgdb -F?
Hello, I've run into problems (most often with p5-* ports) with stale dependencies. I don't know how to solve them other than deleting them, which I know is the wrong way to do it. Currently, I have 2 things I'm not sure how to handle: % sudo pkgdb -F --- Checking the package registry database Stale origin: 'net/isc-dhcp3': perhaps moved or obsoleted. - The port 'net/isc-dhcp3' was removed on 2004-01-18 because: Split in four partial slave ports - Hint: isc-dhcp3-3.0.1.r12 is not required by any other package - Hint: checking for overwritten files... - No files installed by isc-dhcp3-3.0.1.r12 have been overwritten by other packages. Deinstall isc-dhcp3-3.0.1.r12 ? [no] enter OK, so net/isc-dhcp3 went away in favor of -server, -client, etc... How do I proceed though? Do I just answer no to that question and ignore it whenever it comes up until the end of time? Should I deinstall my net/isc-dhcp3 port and reinstall it with the new way? (the new port layout) Stale dependency: pear-DB-1.6.1,1 - pear-PEAR-1.2.1_1 (devel/pear-PEAR): pear-Net_Socket-1.0.1_2 (score:27%) ? ([y]es/[n]o/[a]ll) [no] New dependency? (? to help): devel/pear-Ptab I'm not sure why pear-DB can't find its pear-PEAR dependency in the first place...devel/pear-PEAR still exists in my ports tree. Then I try to name devel/pear-PEAR explicitly (with or without the devel/ prefix, doesn't matter) but that's not found either. Perhaps this is a problem caused by my overzealous deleting of dependencies previously? I'm willing to scrape everything and reinstall, since my ports system is probably very screwed up by now, but I want to learn what the RIGHT way to do things is first so I don't find myself in the same situation 6 months down the road... Thanks for your help, -Paul ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to properly handle stale dependencies with pkgdb -F?
Paul D. Schmidt wrote: Hello, I've run into problems (most often with p5-* ports) with stale dependencies. I don't know how to solve them other than deleting them, which I know is the wrong way to do it. http://www.onlamp.com/pub/a/bsd/2001/11/29/Big_Scary_Daemons.html Michael's article's been real helpful to me. Not quite the bible, but it might be considered canonical nonetheless Kevin Kinsey DaleCo, S.P. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Resolved: How to Handle Stale Dependencies in pkgdb -F
Lee Harr wrote: Is docbook-3.0_2 still registered as installed on your system? I think that is the one it is looking for. It is possible that when upgrading one of the others, that one was removed inadvertently. No, it is not registered as installed. As a matter of fact, none of the docbooks mentioned are installed except dockbook-xsl-1.62.3. In addition, the sgmlformat port is not installed either. I always understood that stale dependencies indicated that a change was necessary. In this situation, the 6 dependencies in question, including the port itself, weren't even registered or installed yet. I just feel that something is missing here. However, I think I'm ready to move on to the next step which is how to respond to the prompt: New dependency? (? to help) : If you hit ?, you'll see: [Enter] to skip, [Ctrl] + [D] to delete, [.][Enter] to abort, [Tab] to complete. I looked at the R-deps listed with the port description and they also correspond to the 6 shown above. As a result, I feel confident that they should be registerd and installed with the port and not the one pkgdb suggests, dockbook-xsl-1.62.3. I assume that I can delete dockbook-xsl-1.62.3, but is that what [Ctrl]+[D] will accomplish? In other words, does new dependency refer to the dependent that it sees as the closest match, dockbook-xsl-1.62.3, or the one that is recorded by the port, docbook-3.1_2? Which would I be deleting? Not sure. Good question though :o) I think there are 2 possibilities: - delete the dependency on docbook-3.1_2 (not the package itself) - delete the entire entry for sgmlformat I am pretty sure that nothing you do at that prompt will affect docbook-xsl in any way. (other than to create a dependency on it) My sense is that it would delete the dependency. In other words, you would be saying sgmlformat no longer depends on docbook-3.1_2 and there is no dependency to replace it In your case, where none of these things are in your package database, I think you have to decide if these are packages you require, and if so, start rebuilding and reinstalling them to recreate their entries. Otherwise, you could pkg_deinstall the one that is giving you problems and move on. I just started using portupgrade myself (after a couple of years of doing these things by hand *erk*) so maybe someone else will chime in and let us know if we are on the right track. Lee, I think you were on the right track from the beginning. The program found sgmlformat-1.7_2 but couldn't locate the dependents it was pointing to so it suggested it's own, dockbook-xsl-1.62.3. Should have focused on the docbook ports at that point. I simply couldn't deal with the idea that installing the docbook dependents would help when the main port, sgmlformat-1.7_2, hadn't been installed yet. Furthermore, I was simply too focused on resolving the issue by using the New dependency prompt. I installed the docbook ports (ran docbook-1.2_1 and the rest followed as deps), followed by pkgdb -F, and everything was OK. Thanks again for your help. Bob ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to Handle Stale Dependencies in pkgdb -F
I think if it were me, I would check to see if the docbook-310 port were still installed correctly, and if not, install it and then try pkgdb -F again. Not sure I understanad the need to examine docbook-310. When I run pkg_info -ro sgmlformat-1.7_2, I get the following: Information for sgmlformat-1.7_2: Depends on: Dependency: xmlcatmgr-1.1 Dependency: iso8879-1986_2 Dependency: jade-1.2.1_5 Dependency: linuxdoc-1.1_1 Dependency: docbook-4.1_2 Dependency: docbook-4.0_2 Dependency: docbook-3.1_2 This is from the dockbook-310 port. The _2 is the port revision. Dependency: docbook-3.0_2 Dependency: docbook-241_2 Dependency: docbook-1.2_1 Origin: textproc/sgmlformat Or, since docbook already depends on all of those other docbook components, maybe you can just point the dependency at the docbook package Do you mean that I can answer the New dependency? prompt with Ctrl-Del? Well... I am not using docbook, so I am not exactly sure. It looks to me like the docbook port may be a meta port to pull in all of those docbook versions. I am not sure if you have that one installed, or if you just have all of the pieces. Is docbook-3.0_2 still registered as installed on your system? I think that is the one it is looking for. It is possible that when upgrading one of the others, that one was removed inadvertently. _ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to Handle Stale Dependencies in pkgdb -F
Lee Harr wrote: pkg_info -ro sgmlformat-1.7_2, I get the following: Information for sgmlformat-1.7_2: Depends on: Dependency: xmlcatmgr-1.1 Dependency: iso8879-1986_2 Dependency: jade-1.2.1_5 Dependency: linuxdoc-1.1_1 Dependency: docbook-4.1_2 Dependency: docbook-4.0_2 Dependency: docbook-3.1_2 This is from the dockbook-310 port. The _2 is the port revision. Dependency: docbook-3.0_2 Dependency: docbook-241_2 Dependency: docbook-1.2_1 Origin: textproc/sgmlformat Or, since docbook already depends on all of those other docbook components, maybe you can just point the dependency at the docbook package Do you mean that I can answer the New dependency? prompt with Ctrl-Del? Well... I am not using docbook, so I am not exactly sure. It looks to me like the docbook port may be a meta port to pull in all of those docbook versions. I am not sure if you have that one installed, or if you just have all of the pieces. Is docbook-3.0_2 still registered as installed on your system? I think that is the one it is looking for. It is possible that when upgrading one of the others, that one was removed inadvertently. No, it is not registered as installed. As a matter of fact, none of the docbooks mentioned are installed except dockbook-xsl-1.62.3. In addition, the sgmlformat port is not installed either. I see now that a major part of the problem was that I never understood what was happening when I ran pkgdb -F. And it wasn't until I read your original note a second time that things became clearer. You wrote: The dependency is recorded as docbook-3.1_2 and it does not see that package, so it is suggesting the package it believes is the closest match. (dockbook-xsl-1.62.3) I always understood that stale dependencies indicated that a change was necessary. In this situation, the 6 dependencies in question, including the port itself, weren't even registered or installed yet. I just feel that something is missing here. However, I think I'm ready to move on to the next step which is how to respond to the prompt: New dependency? (? to help) : If you hit ?, you'll see: [Enter] to skip, [Ctrl] + [D] to delete, [.][Enter] to abort, [Tab] to complete. I looked at the R-deps listed with the port description and they also correspond to the 6 shown above. As a result, I feel confident that they should be registerd and installed with the port and not the one pkgdb suggests, dockbook-xsl-1.62.3. I assume that I can delete dockbook-xsl-1.62.3, but is that what [Ctrl]+[D] will accomplish? In other words, does new dependency refer to the dependent that it sees as the closest match, dockbook-xsl-1.62.3, or the one that is recorded by the port, docbook-3.1_2? Which would I be deleting? Thanks again. Bob ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to Handle Stale Dependencies in pkgdb -F
Is docbook-3.0_2 still registered as installed on your system? I think that is the one it is looking for. It is possible that when upgrading one of the others, that one was removed inadvertently. No, it is not registered as installed. As a matter of fact, none of the docbooks mentioned are installed except dockbook-xsl-1.62.3. In addition, the sgmlformat port is not installed either. I always understood that stale dependencies indicated that a change was necessary. In this situation, the 6 dependencies in question, including the port itself, weren't even registered or installed yet. I just feel that something is missing here. However, I think I'm ready to move on to the next step which is how to respond to the prompt: New dependency? (? to help) : If you hit ?, you'll see: [Enter] to skip, [Ctrl] + [D] to delete, [.][Enter] to abort, [Tab] to complete. I looked at the R-deps listed with the port description and they also correspond to the 6 shown above. As a result, I feel confident that they should be registerd and installed with the port and not the one pkgdb suggests, dockbook-xsl-1.62.3. I assume that I can delete dockbook-xsl-1.62.3, but is that what [Ctrl]+[D] will accomplish? In other words, does new dependency refer to the dependent that it sees as the closest match, dockbook-xsl-1.62.3, or the one that is recorded by the port, docbook-3.1_2? Which would I be deleting? Not sure. Good question though :o) I think there are 2 possibilities: - delete the dependency on docbook-3.1_2 (not the package itself) - delete the entire entry for sgmlformat I am pretty sure that nothing you do at that prompt will affect docbook-xsl in any way. (other than to create a dependency on it) My sense is that it would delete the dependency. In other words, you would be saying sgmlformat no longer depends on docbook-3.1_2 and there is no dependency to replace it In your case, where none of these things are in your package database, I think you have to decide if these are packages you require, and if so, start rebuilding and reinstalling them to recreate their entries. Otherwise, you could pkg_deinstall the one that is giving you problems and move on. I just started using portupgrade myself (after a couple of years of doing these things by hand *erk*) so maybe someone else will chime in and let us know if we are on the right track. _ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
How to Handle Stale Dependencies in pkgdb -F
Hi, Just ran my weekly cvsup program followed by portsbd -Uu. Tried running portsversion -l and received a message indicating that I should run pkgdb -F to deal with a stale dependency. Note following: Stale dependency: sgmlformat-1.7_2 - docbook-3.1_2 (textproc/docbook-310): docbook-xsl-1.62.3 (score:43%) ? ([y]es/[n]o/[a]ll) My understanding here is that I'm to choose between the dependency the port has recorded, docbook-3.1_2, or the one installed, docbook-xsl-1.62.3. I took a look at the sgmlformat-1.7_2 port and found the following: R-deps: docbook-1.2_1 docbook-241_2 docbook-3.0_2 docbook-3.1_2 docbook-4.0_2 do cbook-4.1_2 iso8879-1986_2 jade-1.2.1_5 linuxdoc-1.1_1 xmlcatmgr-1.1 I went back to the prompt in the pkgdb program and indicated no. This was followed by: New dependency? (? to help): Wasn't sure how to respond, so I aborted the program and ran pkgdb -Fa which didn't fix the dependencies either. It did, however repeat the stale dependency prompt for all 6 of the docbook dependencies shown above. Can anyone help me understand what the program is looking for at the new dependency prompt? I was about to respond with a delete command but wasnt' sure what I would be deleting? I did backup /var/db/pkg. Thank you. Bob Perry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
How to Handle Stale Dependencies in pkgdb -F
Just ran my weekly cvsup program followed by portsbd -Uu. Tried running portsversion -l and received a message indicating that I should run pkgdb -F to deal with a stale dependency. Note following: Stale dependency: sgmlformat-1.7_2 - docbook-3.1_2 (textproc/docbook-310): docbook-xsl-1.62.3 (score:43%) ? ([y]es/[n]o/[a]ll) My understanding here is that I'm to choose between the dependency the port has recorded, docbook-3.1_2, or the one installed, docbook-xsl-1.62.3. Not exactly. The dependency is recorded as docbook-3.1_2 and it does not see that package, so it is suggesting the package it believes is the closest match. (note however that it only scores docbook-xsl at 43%) I took a look at the sgmlformat-1.7_2 port and found the following: R-deps: docbook-1.2_1 docbook-241_2 docbook-3.0_2 docbook-3.1_2 docbook-4.0_2 do cbook-4.1_2 iso8879-1986_2 jade-1.2.1_5 linuxdoc-1.1_1 xmlcatmgr-1.1 Seems strange that it would depend on all of those different docbook versions. That may be part of the problem... did you uninstall any of those (or maybe portupgrade did it for you?) Looking at the docbook port, it depends on dockbook-241,300,310,400, and 410 I went back to the prompt in the pkgdb program and indicated no. This was followed by: Good idea, given the low score. New dependency? (? to help): Wasn't sure how to respond, so I aborted the program and ran pkgdb -Fa which didn't fix the dependencies either. It did, however repeat the stale dependency prompt for all 6 of the docbook dependencies shown above. Can anyone help me understand what the program is looking for at the new dependency prompt? I was about to respond with a delete command but wasnt' sure what I would be deleting? I did backup /var/db/pkg. I think if it were me, I would check to see if the docbook-310 port were still installed correctly, and if not, install it and then try pkgdb -F again. Or, since docbook already depends on all of those other docbook components, maybe you can just point the dependency at the docbook package Anyhow. I am no expert :o) Hope this helps. _ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to Handle Stale Dependencies in pkgdb -F
Lee Harr wrote: Just ran my weekly cvsup program followed by portsbd -Uu. Tried running portsversion -l and received a message indicating that I should run pkgdb -F to deal with a stale dependency. Note following: Stale dependency: sgmlformat-1.7_2 - docbook-3.1_2 (textproc/docbook-310): docbook-xsl-1.62.3 (score:43%) ? ([y]es/[n]o/[a]ll) My understanding here is that I'm to choose between the dependency the port has recorded, docbook-3.1_2, or the one installed, docbook-xsl-1.62.3. Not exactly. The dependency is recorded as docbook-3.1_2 and it does not see that package, so it is suggesting the package it believes is the closest match. (note however that it only scores docbook-xsl at 43%) I took a look at the sgmlformat-1.7_2 port and found the following: R-deps: docbook-1.2_1 docbook-241_2 docbook-3.0_2 docbook-3.1_2 docbook-4.0_2 do cbook-4.1_2 iso8879-1986_2 jade-1.2.1_5 linuxdoc-1.1_1 xmlcatmgr-1.1 Seems strange that it would depend on all of those different docbook versions. That may be part of the problem... did you uninstall any of those (or maybe portupgrade did it for you?) Looking at the docbook port, it depends on dockbook-241,300,310,400, and 410 I went back to the prompt in the pkgdb program and indicated no. This was followed by: Good idea, given the low score. New dependency? (? to help): Wasn't sure how to respond, so I aborted the program and ran pkgdb -Fa which didn't fix the dependencies either. It did, however repeat the stale dependency prompt for all 6 of the docbook dependencies shown above. Can anyone help me understand what the program is looking for at the new dependency prompt? I was about to respond with a delete command but wasnt' sure what I would be deleting? I did backup /var/db/pkg. I think if it were me, I would check to see if the docbook-310 port were still installed correctly, and if not, install it and then try pkgdb -F again. Not sure I understanad the need to examine docbook-310. When I run pkg_info -ro sgmlformat-1.7_2, I get the following: Information for sgmlformat-1.7_2: Depends on: Dependency: xmlcatmgr-1.1 Dependency: iso8879-1986_2 Dependency: jade-1.2.1_5 Dependency: linuxdoc-1.1_1 Dependency: docbook-4.1_2 Dependency: docbook-4.0_2 Dependency: docbook-3.1_2 Dependency: docbook-3.0_2 Dependency: docbook-241_2 Dependency: docbook-1.2_1 Origin: textproc/sgmlformat Or, since docbook already depends on all of those other docbook components, maybe you can just point the dependency at the docbook package Do you mean that I can answer the New dependency? prompt with Ctrl-Del? Anyhow. I am no expert :o) Hope this helps. _ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
