Date: Sat, 24 Jun 2006 01:02:58 -0700 From: Doug Barton <dougb@FreeBSD.org> To: Hans Lambermont <hans@lambermont.dyndns.org> Cc: freebsd-ports@freebsd.org Subject: Re: New version of portmaster available for testing Message-ID: <449CF1B2.5060404@FreeBSD.org> In-Reply-To: <20060623084451.GA42262@leia.lambermont.dyndns.org> References: <4491F0AB.7050600@FreeBSD.org> <20060616143045.GA41923@leia.lambermont.dyndns.org> <44939B27.8070501@FreeBSD.org> <20060623084451.GA42262@leia.lambermont.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hans Lambermont wrote: > Doug Barton wrote: > >> Hans Lambermont wrote: >>> Doug Barton wrote: >>>> 3. Add -o option to replace an installed port with a new port from a >>>> different location (e.g., portmaster -o emulators/linux_base-fc4 >>>> linux_base) The second argument can also be specified as the name of >>>> the installed port (e.g., linux_base-8-8.0_15) >>> nice, a hard-needed feature. Can you have multiple -o options in >>> combination with -a ? >> No, you'd have to do all your -o operations individually first. Anything >> else is too messy to try and track. > > Ok, 'was afraid of that. Well this doesn't happen all that often, so IMO the amount of work to handle this special case would outweigh the benefit. >>> 1) >>> portmaster -b -n -a >>> ... >>> ===>>> The devel/gnu-libtool port has been deleted: Has expired: devel/libtool15 is now stock and should be used instead >>> ===>>> Aborting update >>> >>> I think the -n should not abort. >> I've tried to be very conservative with the use of fail() in the script, >> it's only used when something is so far out of the ordinary that it really >> requires user attention/intervention. So, even in -n mode I'm inclined to >> bomb out and let the user sort things out before proceeding. > > Ok, I can understand this reasoning. On the other hand; I like to get a > list of what ports will be updated beforehand, how can I get this list > from portmaster now when the -n aborts ? I can use pkg_version of > course, but that doesn't show build order (or dependencies). What would you think about something like this? http://dougbarton.us/portmaster-listplus.diff > I gave portmaster 1.5 a 3-day-test. Thanks for doing this, and thanks as always for your feedback, it's very valuable. I deleted examples from your post that don't seem to be portmaster issues. If you think my judgment was wrong, please feel free to provide more details. > Here is what I ran into, and what I > did to continue. I'd like to get pointers from anyone for anything I did > that can be improved upon. > # portmaster -GavD > -------------------------------------------------------------------------------- > ===> kdelibs-3.5.3 depends on: /usr/ports/misc/kdehier > ===> Verifying install for /usr/ports/misc/kdehier > ===> kdehier-1.0_9 is already installed > You may wish to ``make deinstall'' and install this port again > by ``make reinstall'' to upgrade it properly. > If you really wish to overwrite the old port of misc/kdehier > without deleting it first, set the variable "FORCE_PKG_REGISTER" > in your environment or the "make install" command line. > Stop in /usr/ports/misc/kdehier. > Stop in /usr/ports/x11/kdelibs3. > # cd /usr/ports/misc/kdehier > # make deinstall > # make reinstall > # cd > ## Can this be done from portmaster somehow ? Not sure what needs to be done here, from what you sent it looks like an error in the dependency list for kdelibs. > # portmaster -GavD > -------------------------------------------------------------------------------- > => kdebase-3.5.3.tar.bz2 doesn't seem to exist in /usr/ports/distfiles/KDE. > => MD5 Checksum mismatch for KDE/kdebase-3.5.3.tar.bz2. > => SHA256 Checksum mismatch for KDE/kdebase-3.5.3.tar.bz2. > ===> Giving up on fetching files: KDE/kdebase-3.5.3.tar.bz2 KDE/kdebase-3.5.3.t > ar.bz2 > # rm /usr/ports/distfiles/KDE/kdebase-3.5.3.tar.bz2 > ## Can this be done from portmaster somehow ? When it launches the 'make checksum' in the background, it should handle this case by refetching automatically (because that's what the checksum target does). But, see below. > # portmaster -GavD > -------------------------------------------------------------------------------- > ## system seems slow, top shows 2 dialogs eating 60% CPU > # pstree > | |-+- 21720 root /bin/sh /usr/local/sbin/portmaster -D -v kde-3.5.2 > | | \-+- 21722 root /bin/sh /usr/local/sbin/portmaster -D -v kde-3.5.2 > | | \-+- 21723 root make checksum > | | \-+- 21877 root [sh] > | | \-+- 21878 root /bin/sh /usr/ports/x11/kde3/scripts/configure.kde3 > | | \--- 21889 root [dialog] > | \-+- 86643 root /bin/sh /usr/local/sbin/portmaster -D -v kde-3.5.2 > | \-+- 86645 root /bin/sh /usr/local/sbin/portmaster -D -v kde-3.5.2 > | \-+- 86646 root make checksum > | \-+- 86798 root [sh] > | \-+- 86800 root /bin/sh /usr/ports/x11/kde3/scripts/configure.kde3 > | \--- 86809 root [dialog] > # kill 21889 86809 > ## what was going on here ? Daemonized distfile fetching perhaps ? Yes. The configure.kde3 script uses dialog, even in the make checksum target. That is, um, weird; although I do see why they do it that way. I'm really not sure how to handle this, so if anyone has a suggestion ... > -------------------------------------------------------------------------------- > # Adobe Reader > Please type "accept" to accept the terms and conditions of license agreement; Type "decline" to exit. > # accept > ## Is there some way to handle this upfront like config ? This halted my > ## build run for hours :-( No, sorry. Things that happen during the port make/install process that are interactive can't be front loaded. However, I will add a check to the dependency tracking and build to warn if IS_INTERACTIVE is set anywhere. I'll probably roll that test in with another optimization that I'm working on, so it might be a while before I have a patch for that. > Can I skip en-openoffice.org-US-2.0.2 somehow for 'portmaster -GavD' ? Adding a list of ports to ignore is on the TODO list. Several people have requested this, but so far no one has sent me an example of how portupgrade flags this (if it's not too hard, I'd like to stay compatible rather than inventing yet another "standard"). If I don't get something by the time I need this feature, I'll have to invent it as I go along. :) hth, Doug -- This .signature sanitized for your protection
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?449CF1B2.5060404>