|Commit found by message id
Fri, 6 Oct 2006
[ 21:50:30 dougb ] |
Manage your ports without external databases or languages
1. You can now specify multiple ports to upgrade on the command line,
such as 'portmaster foo-1.23 bar-4.56 baz-7.98'.  Pass -n argument
to child processes (as needed) to handle this case.
2. Handle an alternate port that can satisfy a build requirement by
reading the CONFLICTS for the "standard" port, and seeing if we have
one of those installed. 
3. Unless the user specifies the new -B option, always build a backup
package when updating an existing port. Unless the user has specified
the -b option, delete the package on successful installation of the
new port, or print a helpful message telling the user where they can
find the package if install fails.
4. Don't only test a port for IGNORE, also test FORBIDDEN and BROKEN
to avoid doing a lot of work on dependencies for a port that we aren't
going to install.
1. Significantly enhance the -r option by tracking what ports should
be rebuilt as a result of it, and rebuilding them "in line" if they
are dependencies of other ports that should also be rebuilt. Thus,
make sure that these ports get rebuilt once, and only once. Also,
don't rely on just the installed port's +REQUIRED_BY file to get the
list of dependencies, since it may be out of date. Search the pkg tree
for that port's DEPORIGIN to make sure that we get them all.
2. Track answers to ports that have +IGNOREME files, so the user is
not asked twice.
3. Rather than use all-depends-list to handle dependencies, use a
combination of build-depends and run-depends. This seems to get
everything we actually need, without sucking in a lot of stuff we don't.
4. Stop abusing the config_only mode, and make a clear separation
between first run (if any) and build run that does not depend on it.
This makes -G mode work as intended, with no bad side effects. 
1. Add PREFIX/sbin to the PATH 
2. Cache "no" answers when using -i ("yes" was already cached).
3. If pkg_version thinks that two versions are the same even though
they have different pkg names, don't warn the user.
4. Clean up package code a little.
5. Twiddle the "waiting on" message for fetch & checksum.
6. If a user has a stale +REQUIRED_BY file in a pkg directory, print a
helpful message that suggests how to fix it. 
7. Don't tell a user about a -r port to rebuild if we're not going to
rebuild it for whatever reason.
1. Clean up trailing white space.
2. If the pkg data is corrupt, a search for installed port by ORIGIN
could return more than one answer. So, use only the first answer.
3. In dependency_check(), if a port has moved, check the new location
to see if it needs updating.
4. If there are no valid ports to build based on the command line
args, don't try to build /usr/ports/ 
 Suggested, debugged, and generally helped greatly by mezz
 Wondered about by yar
 Reminded by Bill Blue
Number of ports [& non-ports] in this commit: 1
Showing files for just one port: sysutils/portmaster
show all files
hide all files
5 vulnerabilities affecting 12 ports have been reported in the past 14 days
* - modified, not new