Forcing port reinstalls without rebuilding over and over again
pschmehl_lists at tx.rr.com
Wed Dec 12 23:12:39 UTC 2018
--On December 12, 2018 at 9:47:14 PM +0100 Polytropon <freebsd at edvax.de>
> On Wed, 12 Dec 2018 13:55:01 -0600, Paul Schmehl wrote:
>> --On December 12, 2018 at 8:41:51 PM +0100 Polytropon <freebsd at edvax.de>
>> > On Wed, 12 Dec 2018 12:52:36 -0600, Paul Schmehl wrote:
>> >> --On December 12, 2018 at 2:07:35 AM -0600 Paul Schmehl
>> >> <pschmehl_lists at tx.rr.com> wrote:
>> >> > Is there a way, using portmaster, to force the rebuild of all ports
>> >> > without rebuilding the same ports over and over and over again?
>> >> >
>> >> > I've noticed that using portmaster -f forces the rebuild of every
>> >> > dependency. I think I've now rebuild perl and python at least 20 or
>> >> > 30 times. Once should be enough. I guess if you're going to rebuild
>> >> > everything, it would be ok to ignore dependencies for ports, since
>> >> > they're all going to be rebuilt anyway.
>> >> >
>> >> > What's the magic potion for that?
>> >> After reading through the man page, I thought that portmaster -Rfd
>> >> would do the trick, but it didn't.
>> >> ISTM that, when you're building every port on a box, you shouldn't
>> >> need to build all the dependencies for every port, because they're
>> >> all going to be built anyway. Rebuilding perl (for example)
>> >> repeatedly, makes no sense at all. It would be nice if there were a
>> >> --force-with-no-dependencies switch so that every port could be built
>> >> once and once only.
>> > Maybe I'm thinking into the wrong direction, but how about
>> > the following thoughts?
>> > The task of building is different from the task of installing.
>> > If you run each build task separatedly, both depencency trees
>> > (build dependencies + runtime dependencies) need to be resolved
>> > from scratch.
>> > For normal usage, and taking your perl example, the following
>> > situation would be present:
>> > 1. port "foo" requires perl as a build dependency
>> > 2. port "perl" is installed and can then be used
>> > 3. port "foo" is built, using the just installed perl
>> > 4. port "bar" requires perl as a build dependency
>> > 5. port "bar" is build, using the already installed perl
>> > (and perl is not built again)
>> > It should work the same with runtime dependencies. This thought
>> > experiment includes the assumtion that the correct _versions_ of
>> > perl are always the same. ;-)
>> It should, but it doesn't seem to.
>> I found this near the end of the man page. I believe I'll try this next
>> Using portmaster to do a complete reinstallation of all ports:
>> 1. portmaster --list-origins > ~/installed-port-list
>> 2. Update the ports tree
>> 3. portmaster -ty --clean-distfiles
>> 4. portmaster -Faf
>> 5. pkg delete -afy
>> 6. rm -rf /usr/local/lib/compat/pkg
>> 7. Back up any files in /usr/local you wish to save,
>> such as configuration files in /usr/local/etc
>> 8. Manually check /usr/local and /var/db/pkg
>> to make sure that they are really empty
>> 9. Install ports-mgmt/pkg and then ports-mgmt/portmaster.
>> Remove both from ~/installed-port-list.
>> 10. portmaster --no-confirm `cat ~/installed-port-list`
> This instruction contains one little thing that _might_ be a
> problem, or at least a nuisance:
> Let's say your installation contains a port "foo" which
> requires the dependency "bar". Step 1 will add "foo" and
> "bar" to your ports list. After the ports tree update in
> step 2, a newer version of "foo" is described, and it no
> longer requires "bar". Step 10 will use the list from
> step 1, and in addition to "foo" (the program you want
> to use), it will also install its dependency "bar" (which
> you have absolutely no interest in).
> In my opinion, it's a little better to create your own
> "top ports list" instead of saving the current state (or
> at least have both lists at hand, but only use your own).
> In that "top ports list", you list the things you actually
> want to use, and you do not care about their depencencies,
> simply because portmaster can resolve them on its own. So
> first, your list is much more readable (as it will only
> contain the software you are interested in, and nothing
> of the software you might need to build or run them), and
> second, your list will be much more portable and also deal
> with the "port not needed, but still installed" problem
> described above.
In general, I agree with you, but there are ports that get installed that I
forget about but are needed. For example, the server I'm working on right
now uses apache, squirrelmail, postfix, courier-imap, and mailman.
Obviously, I would install those right away, because I know they're needed.
But what if I installed something else, that I don't remember (like
saslauthd), but is needed for some functionality that is not a dependency
selected by options?
For example, I run a forum on a webserver that is not a port, but it
requires some ports to be installed for it to work properly. I would
immediately remember that mysql needs to be installed, but maybe I would
forget about ImageMagik or p5-Net-DNS. The generated installed ports list
will catch all that and save me having to remember every necessary port.
That way I don't end up chasing my tail trying to figure out why some minor
functionality that I didn't even notice no longer worked until someone
complained is no longer working. Then I end up having to read logs,
documentation, scratch my head and go, Oh, that's right. I need to install
p5-Net-DNS for that.
Real life is never as straightforward as I'd like it to be, and my memory
isn't what it once was.
Paul Schmehl, Retired
"It is as useless to argue with those who have
renounced the use of reason as to administer
medication to the dead." Thomas Jefferson
"There are some ideas so wrong that only a very
intelligent person could believe in them." George Orwell
More information about the freebsd-questions