Talk:Portupgrade

Revision as of 20:49, 4 July 2006

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.

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 to make 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 -u as 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