Got ports? Here is THE way to upgrade them!
There are many articles on ports in this Diary.
Only a few deal specifically with upgrading your ports. This article beats them all!
Imagine, if you will, a command which allows you to upgrade all of your ports. Stop thinking
about make install distclean. No, I mean one command to upgrade each
and every port!
This isn’t fantasy or fiction. It’s real. And it’s called portupgrade. I first heard
about this great new tool a few months ago, but I never used it until
Michael Lucas wrote
an article about it
in O’Reilly. This was the first time I’ve read about portupgrade.
Coincidentally, I was just starting to install some new ports on my laptop in preparation
for a talk I was going to give at a local Linux User Group.
It wouldn’t do if I gave my presentation on a Windows box….
What I will be giving here will be an overview. You really should read Michael’s article first.
The problem
The ports tree is one of the best FreeBSD features I can think of.
It’s a great way to install software. Fortunately, software gets updated. Unfortunately, some ports expect
a certain version of software. When they don’t find it, they can sometimes get very uncooperative and refuse
to run. When you upgrade a port and force the install (I’ll provide an example later), sometimes other ports
which depend on that newly upgraded port will break. It can become a vicious cycle, upgrading one port after
another as they dependencies flow outwards. Fortunately, portupgrade does this for you.
pkg_version is your friend when it comes to seeing what ports are up to date. Of course, that does depend
upon a recent cvsup of your ports tree. This is pretty easy to do:
# cvsup /usr/share/examples/cvsup/ports-supfile -h cvsup.yourhost.org
where cvsup.yourhost.org is your favorite cvsup mirror. Please
refer to Using CVSup
in the FreeBSD Handbook.
Here’s an example of [manually] upgrading a port upon which other ports are dependant. In this case, I’ve tried to upgrade
devel/glib12 and I’m not upgrading a port, I’m just reinstalling the same
version of an already installed port. Not very useful, but it does illustrate part of the problem.
===> Installing for glib-1.2.10_4
===> glib-1.2.10_4 is already installed - perhaps an older version?
If so, you may wish to ``make deinstall'' and install
this port again by ``make reinstall'' to upgrade it properly.
If you really wish to overwrite the old port of glib-1.2.10_4
without deleting it first, set the variable "FORCE_PKG_REGISTER"
in your environment or the "make install" command line.
*** Error code 1Stop in /usr/ports/devel/glib12.
*** Error code 1Stop in /usr/ports/devel/glib12.
[root@laptop:/usr/ports/devel/glib12] #
You could try doing a pkg_delete, but then you’d get this:
# pkg_delete glib-1.2.10_4
pkg_delete: package `glib-1.2.10_4' is required by these other packages
and may not be deinstalled:
xchat-1.7.8
imlib-1.9.11
fnlib-0.5
gtk-1.2.10
enlightenment-0.16.5_5
ORBit-0.5.7
And you could do a pkg_delete -f glib-1.2.10_4, but that would mess with the
port database (/var/db/pkg). The ports listed above
would then be referencing a version of glib which is no longer installed.
If we were actually installing a new version of the port, the dependant ports would
be pointing at glib-1.2.10_4 instead of the newly installed version.
Installing portupgrade
To install portupgrade, I did this:
# cd /usr/ports/sysutils/portupgrade/
# make install distclean
My environment does not include /usr/local/sbin (the install location
for the portupgrade tools) so
I had to prefix all my commands with that directory. This install actually gives you a collection
of tools. Read man portupgrade for details.
Backup your data
Backup your package database before you start!
# cd /var/db
# tar cvfz var.db.pkg.tgz pkg
Keep that file safe….
Two versions of the same port
Sometimes you can wind up with two versions of the same port installed. For example:
# pkg_info | grep m4 m4-1.4 GNU's m4 m4-1.4_1 GNU's m4
/usr/local/sbin/pkgdb -F is your friend. For simplicity, I’ll only show the interesting bits.
# /usr/local/sbin/pkgdb -F
[Rebuilding the pkgdb in /var/db/pkg ... - 34 packages found (-0 +34)
.................................. done]
Checking the origin of BitchX-1.0c18
Checking the origin of apache-1.3.14_1
Checking the origin of autoconf-2.13
Checking the origin of autoconf213-2.13.000227
Checking the origin of bash-2.04
Missing origin.
Guessing... [Updating the ports database in /usr/ports ... -
6077 port entries found .........1000.........2000........
.3000.........4000.........5000.........6000 (...) done]shells/bash2 (bash-2.05a): Use this? [yes]
Fixed. (-> shells/bash2)
It couldn’t find bash. So it went through /user/ports/INDEX and found the right one and
updated the database. For more information on using pkgdb, see
pkgdb – packages database tool.
Checking the origin of lynx-2.8.4d9 Missing origin. Guessing... www/lynx (lynx-2.8.4.1): Use this? [yes] Fixed. (-> www/lynx)
Then it did similar for lynx.
Duplicated origin: devel/m4 - m4-1.4 m4-1.4_1
Remove any of them? [no] y
Remove the package record of m4-1.4 ? [no] y
-> m4-1.4_1 is kept.
--> Saving the m4-1.4's +CONTENTS file as /var/db/pkg/m4-1.4_1/+CONTENTS.m4-1.4
--> Removing the m4-1.4's record
--> Done
[Updating the pkgdb in /var/db/pkg ... - 33 packages found (-1 +0) (...) done]
Then I was asked about the duplicated port. So I removed the old one, keeping the new one.
Then the ports database was updated with the changed information. But that’s not the end.
Now that a port has been removed, let’s go through the dependencies, because that change
probably affects another port.
Stale dependency: autoconf-2.13 -> m4-1.4: m4-1.4_1 (score:100%) ? ([y]es/[n]o/[a]ll) [yes] a Fixed. (-> m4-1.4_1)
Here, autoconf requires m4 but it’s looking for the old version. pkgdb can update
this for you. If you answer y it will be updated for this port. If you answer a, it will
update this stale dependency for all ports (i.e. change all m4-1.4 references to be m4-1.4_1).
Updating all the ports!
I know this is the command you’ve been waiting for. It is very powerful. So be careful.
# /usr/local/sbin/portupgrade -ra
** The port directory for 'net/cvsup-bin' does not exist.
** No need to upgrade 'screen-3.9.10' (>= screen-3.9.10).
** No need to upgrade 'libtool-1.3.4_2' (>= libtool-1.3.4_2).[snip]
Here you can see that the installed port screen-3.9.10
is at least as new as the one in the ports tree: screen-3.9.10.
So the port is not upgraded.
** No need to upgrade 'autoconf213-2.13.000227' (>= autoconf213-2.13.000227).
** No need to upgrade 'bzip2-1.0.1' (>= bzip2-1.0.1).
** No need to upgrade 'gmake-3.79.1' (>= gmake-3.79.1).
===> Cleaning for XFree86-4.1.0_10
In this case, we’re upgrading XFree86-4.1.0_10.
When I did this on another box, these were the ports waiting to be upgraded:
$ pkg_version -L = apache < autoconf < bash * bind < cclient < cvsup-bin ? gettext * lynx * majordomo < mkisofs < nslint < qpopper < rsync < screen < siege < sudo <
After running portupgrade -ar overnight, this is what portupgrade
had to say:
Updating the pkgdb in /var/db/pkg ... - 34 packages found (-0 +1) . done]
** The following packages were not installed or upgraded (-:skipped / !:failed)
! (cvsup-bin-16.1) (missing origin)
- lang/pm3-base (pm3-base-1.1.15)
- lang/pm3-net (pm3-net-1.1.15)
- lang/ruby (ruby-1.6.5.2001.11.23)
- net/ruby-uri (ruby-uri-0.9,1)
- devel/ruby-fnmatch (ruby-fnmatch-1.1b_1)
- editors/joe (joe-2.8_3)
! net/bind8 (bind-8.2.3) (checksum mismatch)
- devel/libtool (libtool-1.3.4_2)
- devel/gettext (gettext-0.10.35)
- www/lynx (lynx-2.8.4d9)
- irc/bitchx (BitchX-1.0c18)
- misc/pkg_tarup (pkg_tarup-1.2_3)
- devel/ruby-optparse (ruby-optparse-0.8.4)
- sysutils/portupgrade (portupgrade-20011118)
- net/p5-Net (p5-Net-1.0703)
- security/logcheck (logcheck-1.1.1)
- devel/m4 (m4-1.4_1)
- devel/autoconf213 (autoconf213-2.13.000227)
- archivers/bzip2 (bzip2-1.0.1)
- devel/gmake (gmake-3.79.1)
- mail/cclient (cclient-2001,1)
Two ports did mot upgrade:
cvsup-binbecause it could not be found in the tree.net/bind8because of a checksum mismatch. The downloaded tarball did not match
that expected by the port.
I will show you how to get around that bind problem, but you should note that the example I provide
below for bind8 is generic and could be applied to any other port. But also realize
that bind8 is supplied with the base system in FreeBSD. Upgrading it from ports is possible
but you need to follow slightly different instructions. That said, have a read of the
following but keep in mind that I will be installing bind8 again just after this example.
I won't be upgrading cvsup-bin as it's an old port an no longer used on this box.
# cd /usr/ports/net/bind8/ # make distclean
That removed the existing tarball from /usr/ports/distfiles. Then I tried again:
# /usr/local/sbin/portupgrade bind
===> Cleaning for bind-8.2.5
>> bind-src.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
>> Attempting to fetch from ftp://ftp.isc.org/isc/bind/src/8.2.5/.
Receiving bind-src.tar.gz (1329713 bytes): 100%
1329713 bytes transferred in 15.2 seconds (85.61 kBps)
>> bind-doc.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
>> Attempting to fetch from ftp://ftp.isc.org/isc/bind/src/8.2.5/.
Receiving bind-doc.tar.gz (1486296 bytes): 100%
1486296 bytes transferred in 15.0 seconds (96.83 kBps)
===> Extracting for bind-8.2.5
>> Checksum OK for bind-src.tar.gz.
>> Checksum OK for bind-doc.tar.gz.
===> Patching for bind-8.2.5[snip]
===> Compressing manual pages for bind-8.2.5
===> Registering installation for bind-8.2.5
===> Cleaning for bind-8.2.5
[Updating the pkgdb in /var/db/pkg ... - 34 packages found (-0 +1) . done]
That correctly installed the port. However, it did not install bind the way
bind was included with the base system. The above will run, but it won't
replace the built-in bind. To properly replace bind, I followed the
instructions here.
Out of date ports
Even after I cvsup'd my ports, ran portupgrade, one port was still
out of date.
# cd /usr/ports/devel/ruby-optparse
# make fetch
>> optparse-0.8.5.tar.gz is not in /usr/ports/devel/ruby-optparse/distinfo.
>> Either /usr/ports/devel/ruby-optparse/distinfo is out of date, or
>> optparse-0.8.5.tar.gz is spelled incorrectly.
*** Error code 1Stop in /usr/ports/devel/ruby-optparse.
*** Error code 1Stop in /usr/ports/devel/ruby-optparse.
*** Error code 1Stop in /usr/ports/devel/ruby-optparse.
I think this means that the tarball optparse-0.8.5.tar.gz
(which will have been downloaded to /usr/ports/distfiles)
wasn't what the port expected. To be sure I had the latest and greatest, I deleted
the tarball and did another cvsup. Then I did a
# /usr/local/sbin/portupgrade -ra
...and everything upgraded fine.
One port did a bad thing
There was one problem I encountered, but this wasn't the fault of portupgrade.
It was the fault of the apache port which added a www:www user/group combination to my box. But
it overwrote what I already had. Bad port! BAD BAD PORT!
By the time you read this, I'm sure this bug will be fixed.
The problem was many of my webpages could not be read. They were chgrp www, but the group ID (GID) for
www had changed in /etc/group, but the values on disk were the old value.
Here's what it looked like:
-rw-r--r-- 1 dan 99 39229 Nov 2 2000 marc_dan.jpg
drwxr-xr-x 2 dan 99 512 Oct 16 2000 pics
-rw-r--r-- 1 dan 99 19057 Nov 30 2000 proposed_db.gif
See that 99? That is the group ID. That should be a name. The fact
that it is a number means there is no entry in /etc/groups for this group.
This is a result of www being removed and then
added again, but with a different ID.
If the problem were just these three files I wanted changed, I could do it easily.
But here's a script that did the whole disk. Instead of using 99 here,
be sure to use the value used on your system.
find / -user 99 -exec chown www {} \;
find / -group 99 -exec chgrp www {} \;
That fixed up the permissions.
Interactive ports
Another item to be aware of is ports that require interaction during their build.
You might leave portupgrade running over night and come
back and find that a port is waiting for input. For example, mail/majordomo
will display a message at the end of the install and wait for you to hit enter.
And www/mod_php4 asks for configuration values at the start.
Or you can use packages
portupgrade will also install packages, where available, if you
use the -P option. And -PP will use
packages only, never ports.
env: /usr/local/bin/ruby_s: No such file or directory
For details on this problem, please see what Akinori MUSHA had to say.
This was a rather annoying problem. Right after I tried upgrading a series of ports, I was
greeted with this error message.
# /usr/local/sbin/portupgrade -r jpeg
env: /usr/local/bin/ruby_s: No such file or directory
I encountered it more than once. This time it was right after having issued this command:
# /usr/local/sbin/portupgrade -r jpeg ruby ruby-optparse cvsweb autoconf automake expat
I found
it went away if I reinstalled portupgrade.
# cd /usr/ports/devel/linux_devtools]
# pkg_info | grep portupgrade
portupgrade-20011118 Very powerful FreeBSD ports/packages upgrading tool and more
# pkg_delete portupgrade-20011118
# make install
Then it worked fine.
Actually, I may have had to do a make install -DFORCE_PKG_REGISTER.
I'm not sure about this point. I didn't keep notes for that step.
The following notes were provided by Akinori MUSHA after he read the article.
Here is some background stories:
– Prior to 4.4-STABLE, the regular ruby binary that’s installed from
the lang/ruby port used to install its dynamic modules under a
directory with a full (major and minor) system version.
("i386-freebsd4.3" for example)
– So, if you try to upgrade portupgrade, ruby and its modules,
portupgrade fails to load dynamic modules during the upgrading
process if the system was upgraded after the last time ruby and the
friends were installed.
– To cope with the problem, portupgrade and the friends were made to
restart itself with ruby_s[*] whenever it fails to load dynamic
modules.
[*] ruby_s is a statically linked version of the ruby interpreter
binary which you can install from the lang/ruby_static port.
At the same time, the runtime dependency to ruby_s was added to the
portugprade port to keep users away from this trouble.
– At some point of 4.4-STABLE, after the 4.4-RELEASE was released, the
ruby ports are changed to install dynamic modules under a directory
with only a system major version without a minor
version (i386-freebsd4 for example), so that one would not bother
having to rebuild and reinstall all the ruby modules.
– Then it was no loger unnecessary to have ruby_s unless one does
a major upgrade of the system, the ruby_s runtime dependency was
removed.
So, the only case where one bothers with ruby_s is when upgrading
portupgrade that was installed prior to the 4.4-RELEASE (before
4.3-STABLE) or the prevous major OS version to what is currently
installed (like when upgrading 4.4->5.0).
Since portupgrade became really popular after the 4.4-RELEASE, I
didn’t particularly mention the above complex matters in the
documentation.
I’ll probably add some hack to automatically suggest installing ruby_s
as necessary in future, but for now, a piece of advice I can tell is
"install lang/ruby_static before using portupgrade if you have
upgraded your system across versions". I’d also like to emphasize
that it should be safe in theory to upgrade ruby, ruby-* and
portupgrade using portupgrade.
The only problem I’ve had is that sometimes when using X11 4.1 it screws up the dependencies and I’ve got to run pdepfix (or whichever) and straighten them out again.
The other spiffy thing is that it is written in <a href="http://www.ruby-lang.org">ruby</a> which is an easy to learn interpreted scripting language. (Its sloow though, so it isn’t great for everything). I impressed myself with how easy it is to implement things in ruby.
Anyhow, once you’ve got ruby on your system, you may as well learn the language…
Why wasn’t an effort made to merge these with the existing package tools? Portupgrade is nice, but I hesitate to use something nonstandard on a regular basis, especially when the existing tools are almost as good. I use pkg_version -c, which usually does just what I need. Besides the pkgdb, and the dependency fixing, it doesn’t do that much more, and the advantage of pkgdb isn’t much for me. So why not break down, write them in C, and submit some patches to the existing tools?
Not to say that they aren’t handy tools, it just seems like there’s a bit of duplication of effort with them. I do like being able to use abbreviated package names, so I’ll probably keep it around for that reason 🙂
-lx
non-standard? Do you mean not included with the base system?
cvsup for example isn’t standard either (part of the base system that is) but everyone uses it regularily to update their system sources and it works just perfect. So I don’t see what is wrong with using portupgrade and the pkg_tools.
g2k
Forget what he said about "standard" (i don’t know either)
why NOT use
pkg_version -c > update.sh
instead of portupgrade?
the only thing innovative (as far as I know) in this package is pkgdb, which IS very useful
so why not submit this utility to the pkgconfig people?
From the pkg_version man page:
-c Enable commands output. Commands output includes the commands
you should type to update your installed packages to the latest
versions in the ports system. This feature does not constitute
an automated packages updating system. The output of this com-
mand must be edited, in order to avoid destroying dependencies
between installed packages.
I take the descriptions of portupgrade to mean that it will chase down all of those depending packages and change the version of the dependency in their DB entry to that of the newly upgraded port.
Not all ports should be upgraded this way.. You forget that there are ports such as Mysql and apache-ssl and php3 and php4 that require some level of interactive work to upgrade them in the ports collection.
You should before suggesting that people not use an interactive portupgrade, suggest that they do not in fact use softwares that have at any point been user interactive or that require special attention because of ssl keys or installation of a database which is not required due to previous installation.
Portupgrade is *NOT* a standard and should not be viewed as such simply for the fact that its not intuitive enough to know that there is a very real possibility that it could screw up a current software installed on the system such as what happened with apache-ssl on my system at one point.
Without realizing it I ended up completely trashing my apache server and had to reinstall all configurations and ssl keys from a backup.
Before all else people need to be reminded of these things so keep it in mind before you go making it sound like you can just drop a cron process in and allow portupgrade to do all the work without user interation. It truly does make a difference with a larger number of ports in the fbsd system.
Rob
In my experience, running portupgrade prompt on interactive ports, the same way the ports themselves do….. unless the recursion feature turns it off…
You are correct. Portupgrade will prompt you for the information required.
Rob wrote:
>
> Not all ports should be upgraded this way.. You forget
> that there are ports such as Mysql and apache-ssl and php3
> and php4 that require some level of interactive work to
> upgrade them in the ports collection.
I didn’t forget. In fact I used portupgrade to upgrade these very ports. No problems.
> You should before suggesting that people not use an
> interactive portupgrade, suggest that they do not in fact use
> softwares that have at any point been user interactive or
> that require special attention because of ssl keys or
> installation of a database which is not required due to
> previous installation.
I never had any such problem.
> Portupgrade is *NOT* a standard and should not be viewed as
> such simply for the fact that its not intuitive enough to
> know that there is a very real possibility that it could
> screw up a current software installed on the system such as
> what happened with apache-ssl on my system at one point.
What makes you think it is not standard?
> Without realizing it I ended up completely trashing my apache
> server and had to reinstall all configurations and ssl keys
> from a backup.
Accidents do happen. That’s why we have backups.
> Before all else people need to be reminded of these things so
> keep it in mind before you go making it sound like you can
> just drop a cron process in and allow portupgrade to do all
> the work without user interation. It truly does make a
> difference with a larger number of ports in the fbsd system.
Ummm, I never mentioned a cron process for upgrading ports. At no time did I mention anything close to that.
Now, where was I wrong?
i really wish i had read this post before portupgrade trashed my box. I think that if i ever get my box back to normal, which I am afraid is going to take about a month of chasing down what I need to backup, and then a complete reformat, and fresh install, then i’ll have to recomile again with my kernel, then I will have to reinstall 230 something ports, some of those are dependecies, yes, but i still have way to many apps to reinstall, reconfigure, retest, F#$K
My advise to anyone considering using portupgrade, is silply DO NOT DO IT
MarkC wrote:
> i really wish i had read this post before portupgrade trashed
> my box. I think that if i ever get my box back to normal,
> which I am afraid is going to take about a month of chasing
> down what I need to backup, and then a complete reformat, and
> fresh install, then i’ll have to recomile again with my kernel,
> then I will have to reinstall 230 something ports, some of
> those are dependecies, yes, but i still have way to many apps
> to reinstall, reconfigure, retest, F#$K
Sounds like something went wrong. I use portupgrade on a regular basis, for production systems.
> My advise to anyone considering using portupgrade, is silply DO
> NOT DO IT
I’m not sure that’s sound advice at all.
What version of FreeBSD were you using? What portupgrade command did you issue? What error messages are you seeing now?
—
The Man Behind The Curtain
I tried to follow your instructions but get pkgdb: command not found errors. When I try to find it I get this:
chip# locate pkgdb
/usr/local/lib/ruby/site_ruby/1.6/pkgdb.rb
What am I missing? Is portsdb -Uu the same thing? I am running it right now anyway.
try /usr/local/sbin/pkgdb
note: locate is updated automagically once a week. You won’t find just-installed files that way. Either use find, or see man locate to manually run the update program.
Well, find was unable to find it also –
find: pkgdb: No such file or directory
bash-2.05$
What port do I need to install to install pkgdb? I checked the fbsd.org web site and couldn’t come up with anything.
Chip wrote:
> Well, find was unable to find it also –
>
> find: pkgdb: No such file or directory
> bash-2.05$
I found it:
$ find /usr/local/sbin -name pkgdb
/usr/local/sbin/pkgdb
$
> What port do I need to install to install pkgdb?
The article is all about portupgrade. pkgdb is part of portupgrade.
I understand that, and I have the port portupgrade installed, as shown here:
chip# pkg_info | grep portupgrade
portupgrade-20010912.2 Very powerful FreeBSD ports/packages upgrading tool and mor
chip#
Yet I don’t have pkgdb, as shown by the find command in the previous message.
So I am missing pkgdb, I did pkg_delete of portupgrade and then reinstalled it, a newer version – 20011231, now I have pkgdb. What do ya know – it wasn’t part of the older version I had installed.
The first rule of thumb with ports when ecountering a problem is to cvsup your ports tree and try again.
I just did cvsup last night (and once a month), I just had an old version of portupgrade installed. I didn’t know it was so out of date (it was working fine for upgrading other ports). Now with pkgdb I can keep all my installed apps up to date more easily.
btw: you could have done a "portupgrade portupgrade"
It’s done. Took a day and a night to finish, it stopped several times needing input – specifically apsfilter and something else, I don’t remember what. But it’s done. One note though – All my custom desktop settings are gone. I guess this didn’t happen to you, or you would have mentioned it in your article? The wm I am using is XFCE if it matters.
When I try to run pkgdb- F I get the following error:
/usr/local/sbin/portupgrade:34:in `require’: No such file to load — optparse (LoadError)
from /usr/local/sbin/portupgrade:34
If I try to portupgrade portupgrade, I get the same error.
Any ideas?
Hi there
It’s been a while that this message was added in the list, but I get the same message trying to use any program which comes with this portupgrade tool. I am using a stable 4.5 version of FreeBSD.
Best regards,
Kevin
[%sig%]
Hi all,
I think I had the same problem, it means after I`ve installed portupgrade using ports I was trying to build /var/db/pkg but when I run #pkgdb -F or #portupgrade -a command the following error occured:
pkgdb: command not found,
So I use rehash command and everything was fine. In some shells it is essential to use rehash command after using any of newly installed programs.
BTW my system is FreeBSD 4.10
Actually not only the apache port is doing bad things,
there are several other ports that upon their installation do bad things to their previous working condition.
to be more specific I encountered with this problem with the cvsup-mirror port.
The port checks if cvsupin:cvsupin uid/gid exist, and doesn’t create new ones if they do.
But what it doesn’t check is whether the /home/ncvs (the whole cvs repository) is owned by these uid/guis or not.
and it executes:
"Fixing ownerships and modes in …."
which is actually a chown -R on the whole /home/ncvs dir.
and that is a Bad Thing, because it’s already chowned.
and this is a waste of cpu/io.
There is also the gdm (gnome xdm) port, that always "rewrites" it’s configuration files. Instead of creating new ".sample" ones.
Maybe there are some other ports that I had problems with, but I don’t remember right now.
I suggest you contact the ports mailing list and the port maintainer to let them know of this problem. I also suggest submitting a PR.
I’ve read about portupgrade on some other occations too. I have been using another alternative for a long time.
This does the trick for me:
pkg_version > update
vi update #edit as necessary, for ports you don’t want to upgrade, etc
chmod 700 update; ./update
Am I missing something? This has been a feature of pkg_version for quite some releases.
db
the trick of course, is
pkg_version -c > update,
not simple pkg_version > update.
portupgrade -R only upgrades the packages you _need_ upgrade, where with pkg_version -c you would have a lot of editing to do.
note the difference between -R and -r:
-r
–recursive Do with all those packages depending on the given
packages as well.
-R
–upward-recursive Do with all those packages required by the given
packages as well. (When specified with -F, fetch
recursively, including the brand new, uninstalled
ports that an upgraded port requires)
Apache was one of the ports that needed to be updated. Aparently portupgrade overwrites certain directories in the process of running. Specifically /usr/local/www/data!!! Fortunately it shouldn’t take me too long to rewrite what I lost, but I won’t be running portupgrade again until I figure this out.
Is this expected behaviour, or did I do something wrong?
I would document everything you did, see if you can reproduce it and let freebsd-ports@freebsd.org know about it. Include the version of portupgrade you were running.
hi,
I installed on freebsd 4.5 xfree86-4. INDEX file says it is xfree86-4-1.xxx and so on. I need xfree-4.2.xxx.
However, portupgrade does not upgrade to this latest version.
However, it is the latest for 4.6 ports and not 4.5.
How does portupgrade work on this? Does it take all ports for all versions, or only your version the latest.
If I am wrong, then why does portgrade not update my 4.1 to 4.2?
hc
Take a look at configure.php. There are two environment variables you can set. BATCH and PHP4_OPTIONS. Look for this when you have interactive menus. Applys to mod_php3 also.
You can skip the PHP4_OPTIONS (look in configure.php) and it will set zlib and MySQL for you.
For example:
export BATCH=1
portupgrade -v mod_php4
Enjoy!
Exactly how do you set PHP4_OPTIONS? Do they need to be in quotes? Escaped quotes? Or just list them using a space to seperate each option?
well now that you have shown me how to totally screw up my box with portupgrade… is there any way that i can undo it so that i can have my applications work correctly again. there is little i would sacrifice over security (like patching applications) but I must admit: working applications with lesser security is better than one that dont work at all because portupgrade fried them
so please, if you will… what is the command now to undo your advice or running portupgrade?
My advice? What, in particular did you do?
Without knowing what’s wrong, I can’t help you. "totally screw up" doesn’t tell much.
Portupgrade, like any tool can be used to mess thing up.
—
The Man Behind The Curtain