Talk:Portupgrade
note on the rollback: I strongly prefer showing a pipe to grep rather than the -l argument because they both accomplish the same thing, but piping to grep is a universal tool than can be used with any command or process. It's a good habit to learn using tools and skills that are universally applicable as opposed to stuff that's only applicable to one particular task, unless there is some marked advantage to using the more proprietary method of doing things.
If you know of some particularly good reason to use the -l argument instead of piping to grep, by all means let me know here. --Jimbo 19:23, 9 Jul 2005 (EDT)
The goal is just avoiding to use two processes when only one is needed... More, I tried this :
Script started on Sun Jul 10 11:35:19 2005 # time portversion -l '<' > /dev/null portversion 1.90s user 0.68s system 86% cpu 3.001 total # time portversion | grep '<' > /dev/null portversion 2.68s user 0.88s system 69% cpu 5.102 total grep '<' > /dev/null 0.00s user 0.00s system 0% cpu 5.100 total Script done on Sun Jul 10 11:36:23 2005
I do not know how it work internaly, but I gess that the "-l" argument changes the search algorithme.
But I agree with your point of view... grep has to be known by the users ! The "-l" flag may sometimes be preferable, for a low system for example...
Yah, if I was scripting repeated operations, by all means I'd use the more efficient way. But in general I think the modularity of *nix is actually by far the best thing about it, and I try to do things as modular as possible if there isn't a compelling reason to do otherwise. Even in my own just day-to-day stuff; sure I already know about grep, but still actually using it for everything keeps me in the habit of using it and that's more useful to me than being in the habit of using something that only applies to portversion, y'know? =)
Btw, the difference in efficiency isn't anywhere near as compelling on my systems:
ph34r# /usr/bin/time -h portversion -l '<' > /dev/null
0.88s real 0.70s user 0.18s sys
ph34r# /usr/bin/time -h portversion | grep '<' > /dev/null
0.89s real 0.68s user 0.21s sys
or
blackbox# /usr/bin/time -h portversion -l '<' > /dev/null
1.03s real 0.83s user 0.18s sys
blackbox# /usr/bin/time -h portversion | grep '<' > /dev/null
1.04s real 0.83s user 0.19s sys
On looking again at your times, I notice that the CPU% is quite a bit higher on the faster score. I have a sneaking suspicion a cron job or something kicked in while you were running the second one, so it just didn't get as much processor time and took longer.
--Jimbo 11:52, 10 Jul 2005 (EDT)
As my load average is about 1.0, I have done my tests 4 or 5 time to check that the result was always the same (it was)... But it may not have incidence on the statistics since they are updating by the kernel when the process is effectively running and collected by the time command by reading a data structure filled by the wait4() system call (If I don't remember wrong, time fork() itself, exec() the command and wait4() for it)...
What I think is that the execution time can be dependant of the number of results : As I might have everyting up to date, i might have the greater difference I can get (all the ports vs. none)...
Well... I have nothing to conclude from this ... All the two methods do the same :) --Smortex
I'm betting it has to do with your high average load. I generally work with fairly high-powered servers in relatively small environments, with load frequently averaging as low as .05 even during working times. (PS: when you're writing in talk pages, you might want to use the signature button (looks like a little squiggle up at the top of the textarea) to sign your comments, or if you're using a non-graphical browser, you can get the same effect by using --~~~~ as a code.) =) --Jimbo 18:55, 10 Jul 2005 (EDT)
05/30/06 I notice that there is no mention to doing a CVS before using portupgrade; also no mention of the INDEX file being remove. Should these aspects be addressed?
absolutely... address 'em! --Jimbo 00:14, 31 May 2006 (EDT)
I just started to use FreeBSD again; so I have to do some research about it before I make a comment. Thanks Jimbo. Wed, June 7, 2006 7:51 AM CDT.
Contents |
Putting the pieces together for portupgrade
Portupgrade depends on INDEX-6 and INDEX-6.db to function properly. As of release 5.4; INDEX-6 and INDEX-6.db are not part of the download from CVSUP. You have to build or make the INDEX* files.
1) cvsup -g -L 2 ports-supfile
2) Update the INDEX files via the three methods listed below (a,b,c):
a) cd /usr/ports, then "make index" b) cd /usr/ports, then "makefetch index" c) cd /usr/ports, then portsdb -Uu
3) Then upgrade your ports as described in the methods described above.
A caveat should be mentioned about the methods of obtaining the INDEX files. Option a) "make index" is officially supported by FreeBSD. Option b) is supported by FreeBSD; however, please keep in mind that the INDEX files that are retrieved from the servers may be slightly out of date; which may cause build problems. You may have to change the premission on the download INDEX files via (chmod to match the premissions: "-rw-r--r--". Option c) portsdb -Uu was never offically announced as being acceptable or not acceptable. Portsdb -Uu does create/build and update the INDEX.
My method of upgrading ports is: Step 1, step 2c and then step 3.
The approved methods can be found here as well as the blurb about removing the INDEX files from CVSUP in section 2.5:
http://www.freebsd.org/releases/5.4R/relnotes-i386.html
--68.164.11.90 15:54, 2 July 2006 (EDT)Hope this helps. Pete
- Thanks for the notes. It would be helpful to add them in to the article. The target is make fetchindex (rather than makefetch index). Running make index builds an up-to-the-minute Index. You might also mention that, make index is very, very slow.
portsdb -U"creates/updates the Index" by a system call tomake index, so it's just as slow. There's a port in sysutils/p5-FreeBSD-Portindex, which is a set of perl scripts that incrementally keeps the Index updated, by using a cache of previous output. At least in theory, this should be faster; but I haven't used the port.
- Portupgrade runs
portsdb -uas part of its routine before building, and between each build - so, I can't see the advantage of the extra precaution of running portsdb -Uu before running portupgrade (portsdb -U would seem sufficient). On the other hand, this is the procedure recommended on the portsdb man page, and the -u doesn't cost a lot of time. Ninereasons 13:53, 4 July 2006 (EDT)
- Hello Ninereasons, I put this in the discussion section; to see if there could be a consensus of users; aka a peer review of bsd users. I am somewhat hesitant to make any official changes to a wiki until I get some feedback as well as proof reading what I have written (IE: the "make fetchindex" typing error). As for the extra tools; with respect to managing / updating the index; I would like to see this as bare metal as possible. In other words; the tools exist to update the index; no need to add more tools (imho). I am trying to look at it from a new users perspective. I could very well be wrong or misguided in that view. PS: never used a wiki before; I don't wish to break the original documentation. PSS: thanks for the feedback.
--68.164.11.90 21:49, 4 July 2006 (EDT)Pete
- Hi Pete. You can call me "Mark". The beauty of a wiki is that you won't "break the original" by making a useful contribution like the one you're contemplating. If you make mistakes, we'll fix them. If you seem to be wrong, which isn't the case here, we would just restore what you messed up - and no hard feelings. I'm a guest here, just like you. But even as a guest, I can invite you to log in with a username and give it a try. Ninereasons 01:03, 5 July 2006 (EDT)
hey Pete
How about registering an account and using it, if you plan on being a recurring contributor?
It's not required by any means, but it makes it a lot easier for the rest of us to keep track of who's who (and whether or not a new edit is likely to be spam or vandalism).
Thanks, and welcome to the wiki! --Jimbo 23:01, 4 July 2006 (EDT)
Hello Jimbo and Mark; thanks for the remarks / input. I think I will be hanging out here. On a side note; what is the license for the wiki? Can some of these changes be submitted back to FreeBSD.org? Pete--PeteX 19:54, 6 July 2006 (EDT)
Creative Commons
feel free to submit back. just, whenever possible, try to attribute and get folks to come back here as well. =) --Jimbo 23:22, 6 July 2006 (EDT)
Additional Tools part of portupgrade
There are several tools that come with portupgrade; a list can be found here: http://www.freshports.org/sysutils/portupgrade/ Should some of these be created in the top part of the article and linked back to their respective pages? Any thoughts? PeteX Aug 15, 2006 (CDT)
portsnap and portupgrade
with portsnap's take over of cvsup, how can portupgrade still be used? how does one automate port upgrades when switching to portsnap from cvsup?
thanks -s
This Page Needs Updating
Can a knowelgable person update this page? It is still mentioning "cvsup" and from everything I have read - the prefered choice for updating the port tree now-a-days is by using "portsnap fetch update". --4 MAY 2010
out-of-date to the point of being a historical curiosity
there's not really a whole lot of reason for this page to even be here anymore, truth be told - port management has moved on. added a note to that effect at the top of the article. thanks for nudging me! --Jimbo 00:06, 5 May 2010 (UTC)
Wass up
I am new here.Never been in forum before.Please accept me to be a part of this forum.I guarantee to share.
I have a web site about <a href=http://www.n-tv.de/technik/Provider-verraten-Kundendaten-article3470311.html>copyright watch abmahnun</a> and if somebody is curious about that topic I wish that they will browse it.
