Is there way to build all dependencies in parallel to install them manually later?

[salam4ik]

Hi to all!
I have found that keeping ports up to date is very difficult problem. 2 weeks ago had updated all ports on my laptop, it took about 3 days for build and install them. Today I again have updated ports tree by portsnap, and now I am very upset, because I have to upgrade them again. Actually, problem for me only huge ports as xorg, gtk, qt4, because I need to close all applications that use them. So, is there way to config and build paralelly all ports, which need update, and then manually install them after all proper programs will be closed?

Thank you for your help!

 

[jb_fvwm2]

There is a way for *some* using one machine.
And several ways to upgrade *all* using many
machines, and variants.
(Another thread details how, somewhat, passing
.so. files to /usr/local/lib/compat temporarily
in the thread discussing "gettext") (see my
posts in that thread to read more).
However, if more than one small group of .so. files
are going to be updated, that would become more
complex and not easily doable. People use
"build servers" "jails" "tinderbox" etc but I am
not qualified to detail how.
.....
OTOH you do not *have* to upgrade.
Say you use gnome, and before gnome is bumped,
you have the following:
(the result of

 | tee -a [filename]

passed from pkg_version with switches
...
abiword
gstreamer-plugins
meld
pango
....
in a file (the result of pkg_version with switches)
that details what needs to be updated
(say, file_orig)
Then gnome is bumped and it adds
glib20
gtk20
gnome-keyring
liblqr-1
poppler
....
etc etc
Then one can run the pkg_version again
and obtain a new larger file
file_second which details about 9 ports
(the first and the second files.)
You may think, "that is a lot." But you can
delay it thusly...
rename the second to
file_second.TXT
Then wait a few days. Run the pkg_version again,
obtain a new larger file_third (a few more ports
to update, say 15 rather than 9
(So you have three files so far). Ignoring
the first, obtaining a fourth (maybe) if you
tee the following to disk:

sort file_second.TXT file_second.TXT file_third | uniq -u

If my assumptions are correct, you now have in the output
only the six newer (That i've not listed herein ) that
are SINCE file_second.TXT. You can examine their
run-depends-list, build-depends list contents and only
upgrade them if they are not dependent upon glib20,
gtk20, pango etc.
....
I assume with this method one can upgrade many ports
all at once only when one has the time, and upgrade just
a few *usually*
....
(the above a "first draft" so hopefully contains no typos)
(Sorry if it does not answer some of the questions. I was
wondering if I should post it at all, yesterday at this
time about.)

 

[jb_fvwm2]

Unsure to bump this thread or start a new one, but
x264 and ffmpeg and some gstreamer were just updated.
(and today, the "next day", gnome)
Persons wanting to avoid rebuilding lots of multimedia
apps might want to use the above "uniq" method
(which I recently found works somewhat the same
with "wdiff file1. file.7" IIRC)

sort file.1 file.1 file.7 | uniq -u | lookat

(lookat/ substitutes for "more" "less" etc)

The latest "file.7" today shows I need 311 ports
updated. Howsoever, the "uniq" command-line (above) pares
that down to 119 (today) from which I can easily
write down the few recent non-gnome ones.
(june 03 : file.1)
(july 24 : file.7) in this case.

APOLOGIES: changing the filenames from the original post.
(file.1 is the first " | tee -a " from grepped pkg_version)
(file.7 is the "later week" same file)
I might have omitted some parts of the actual
command lines, but if anyone tries this and gets
not-alike results they can point out where the error
is in the referenced post above (or where it can
be made clearer.)

IOW this methodology this week should save the
machine here several hours of downtime that I
might have otherwise planned due to less
pre-planning expertise.

 

[jsa@]

Take a look at ports-mgmt/pkg_jail. Once you have it setup proper, from within the jail's port tree run:
# make package-recursive

Do this for the packages you want, i.e. x11/xorg. It will build packages for everything you need to install xorg without overwriting the ones in your base.

You can find which ports you specifically need to replace by running:
$ pkg_version -l \<

Then just replacing those packages specifically with the new ones you built inside the jail.

Also portmaster(8) (ports-mgmt/portmaster) has some great functions you can use within the jail to keep building up-to-date packages without having to rebuild all the depends each time.

The downside to the above methods is that you essentially have two copies of the OS and all packages taking up space. But assuming you aren't doing anything foolish with your /etc/make.conf, the resultant packages will be portable to all machines of the same architecture, i.e. i386, amd64, sparc, etc.

If you have a faster desktop machine, you might consider using it (or a virtual machine install on it) to build your packages, then just moving them to the laptop.