Bug 227347 - ports-mgmt/portmaster: unnecessarily recompiles flavored dependencies
Summary: ports-mgmt/portmaster: unnecessarily recompiles flavored dependencies
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Stefan Eßer
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-04-07 15:21 UTC by Martin Birgmeier
Modified: 2020-01-23 16:47 UTC (History)
2 users (show)

See Also:
bugzilla: maintainer-feedback? (se)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Birgmeier 2018-04-07 15:21:47 UTC
It seems that whenever a dependency does not specify an explicit flavor for a port which is flavored, portmaster reinstalls it unconditionally. For example, running "portmaster devel/llvm50" will recompile py27-enum34 and py27-sphinx, even though both are already installed in their latest versions.

I think portmaster should be modified such that when checking whether a port needs to be updated it first checks whether the port is flavored (probably using "make -V FLAVORS"), and if it detects that it indeed is changes the update check to be for the default flavor instead ("make -V FLAVOR" where the environment does not include the flavor).

There are quite many ports whose dependencies have not been marked (completely) with a flavor, and it probably should not be necessary given that a default flavor exists anyway (there were however a few commits where most of the flavors for python dependencies were added).

-- Martin
Comment 1 Walter Schwarzenfeld freebsd_triage 2020-01-19 07:40:09 UTC
see also: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227347
Comment 2 Walter Schwarzenfeld freebsd_triage 2020-01-19 07:42:17 UTC
(In reply to Walter Schwarzenfeld from comment #1)
Sorry, this was paste error.
Comment 3 Walter Schwarzenfeld freebsd_triage 2020-01-22 23:51:29 UTC
Should solved after ports r523835.
Comment 4 Martin Birgmeier 2020-01-23 16:47:50 UTC
Thanks for committing the fix, it seems to work!

-- Martin