pkg_add -r kde4 VS portinstall -P --batch x11/gnome2

achix

achix

Hello, (dont shoot me because of the oranges vs apples thing!)

After 13 years of FreeBSD usage, it seems sometimes I am still at level 0. Just tried to upgrade our house computer from 7.1 to 8.2 (386), did world and kernel, deleted all packages (btw it seems that [CMD=]pkg_delete -af[/CMD] is way too slow compared to [CMD=]pkg_deinstall -af[/CMD]), then from a clean system, I tried last night with portinstall -P --batch x11/gnome2 in order to get done with all the non-interactive stuff, only to find out in the morning that the port count had gone from about 400 late last night, to 480 in the morning because some port (avahi) didn't want to compile, and the messages pointed me to turn my attention to the gnome camp.

I said, what the heck, lets try kde4 instead, but with [CMD=]pkg_add -r kde4[/CMD] this time. I issued the command, went to some celebration the kids had in school, went to work, logged in the home computer, [CMD=]screen -d -r[/CMD], inspected the script log, and everything had gone just lovely!

So the natural question is, since both pkg_add -r and portinstall/portupgrade both seek packages in ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8.2-release/All/ , then why pkg_add -r seems to usually work while portinstall -P seems to usually do the opposite and consume days and nights without much work been done?

Two days before, I bought a computer for the rest of the family, had all their data migrated there, it is a modern phenom 2 X4 based with 8 GB mem. I installed Kubuntu, and in fact I was surprised that it was not SO much easier than someone would expect. Nevertheless with Kubuntu (with zero Kubuntu experience, but rather good Linux/Debian experience) I managed to have a full working machine in 2-3 hours (this included downloading and burning an additional ISO, and configuring with software raid1 on all partitions). With the FreeBSD box I am still struggling after 24 hours, and it's like my Nth FreeBSD upgrade/installation.

Frankly I think, the FreeBSD package management need something more "focused". we are not in 1997 with the 900 different ports around or with the 50 different peripheral devices. Now we have 20,000 ports and more complex kernel/world as well, while the hardware not getting substantially faster.
 
Hmm came up with an idea.

Maybe pkg_add uses ".../ports/<arch>/packages-<major/minor release>/<All|Latest>/"-derived dependencies, in order to achieve its depth-first search order of determining dependencies and installing them, while portupgrade/portinstall use "/usr/ports"-derived dependencies.

So, while the transitive closure of interdependencies seems to be self-contained in the first case, the ports systems, OTOH always evolves, so there is no way that after days or even hours after the release, that /usr/ports system changes will be reflected in the directory of compiled packages.

So bottom line:
Want to kickstart your system to have something to work in/on? Go with [CMD=]pkg_add -r[/CMD] and be safe.
Want to have a perfectly modern system just after installation of ports? Go with [CMD=]portinstall -P[/CMD].
Want to upgrade your system? Go with [CMD=]portupgrade -P[/CMD].

Feel free to omit -P (which stands for "prefer precompiled packages instead of building them) or add other switches at will.

SOLVED!!
 
Another option...
Has there been over a month from the last release? Have the ports tree evolved too much? Maybe taking days to build everything up to date?
Well, in this case there is PACKAGESITE env variable. In the case of 8.2-RELEASE just set
# setenv PACKAGESITE [url]ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8-stable/All/[/url] and you are done! Be cautious though to not forget this variable in some .cshrc file.
Anyways, I believe that some magic could be added to portupgrade to at least provide an experimental option to achieve that automatically.
 
/usr/local/etc/.portmasterrc (I think). Set PACKAGESITE in it. Then
Code: 
portmaster -d -B -P port... port... port...
to expand on the previous post
 
No idea about portmanager but compared to portupgrade, portmaster is 100% shell script based, uses no external db's and is really faster.

Try it.
 
Portmanager used to work really really well. For some reason it either segfaults and/or gives false negatives to installed ports... Hoping that someday it would work as before, it had really cool "checking..." after which you could cntl-c the actual work and have a succinct list of
stuff you can do piecemeal if need be, if the command was | tee'd or... (that is one one machine here at least. Haven't retried on the more
current (CURRENT) ones.)
 
It's better to install kde4 modularly than as a single package. There's too much cruft that gets installed when one does installing by a single command.

Apply the same to gnome2.
 
Unfortunately that would require week(s) of standing in front of the monitor. Software has gotten huge these days, and the home computers simply cannot cope with this any more.
 
I'd simply wait a few weeks past the most recent gnome bump, set the PACKAGESITE as above (to -stable, or -current, not -release) , and select the few gnome apps you would be using most often:
Code: 
portmaster -d -B -P www/firefox
etc. Although if that port needs building, not a package, on this machine it could fail due to needing too many gigabytes. (Only a few ports that I know of).
...
One might want to bump python26 to python27 etc beforehand; for instance the seamonkey package requires the latter.
 
achix said:
Unfortunately that would require week(s) of standing in front of the monitor. Software has gotten huge these days, and the home computers simply cannot cope with this any more.
Click to expand...

The default settings are worthless if:

1) A person is not using an x86/amd64 system.
2) A person does not have equipment such as a printer scanner, etc and does not plan on purchasing such equipment.
3) A person is running a testing system.

One could always check occasionally for when the build stops at an option, make the selection, and go back to doing whatever.
 
sossego said:
The default settings are worthless if:

1) A person is not using an x86/amd64 system.
2) A person does not have equipment such as a printer scanner, etc and does not plan on purchasing such equipment.
3) A person is running a testing system.

One could always check occasionally for when the build stops at an option, make the selection, and go back to doing whatever.
Click to expand...

1) 99% of the users run x86/amd64
2) even the cheapest printers/scanners these days have network connectivity
But then again, this is hardly relevant. You could always kldload the module from the GENERIC kernel and get done with it. Or further subclass ports like Debian does.

I could add that 99% of the ports need not be customized (would you ever care for the options of lets say enchant or gpsd or py-qt4-phonon?), well you could, but this is very rare, and I cant see a reason why 99% of the users should suffer for the sake of the ones experimenting with software. Don't get me wrong, having full control of the system is great, but most of the times certain things you want to get them fast.
 
You must log in or register to reply here.
Back
Top