Date: Thu, 14 Feb 2008 13:46:08 -0800 From: Doug Barton <dougb@FreeBSD.org> To: "Aryeh M. Friedman" <aryeh.friedman@gmail.com> Cc: freebsd-ports@FreeBSD.org, sem@FreeBSD.org Subject: Re: portupgrade-devel: 2 feature requests Message-ID: <47B4B6A0.6090200@FreeBSD.org> In-Reply-To: <47B487DE.5090609@gmail.com> References: <47B47052.8010404@gmail.com> <47B481E5.3010000@FreeBSD.org> <47B487DE.5090609@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Aryeh M. Friedman wrote:
> Doug Barton wrote:
> The idea is more along the lines of knowing how far you are away from
> completing the whole build
... and I repeat my thesis that what you're really interested in is
how much time is left, not how many ports are left to build, and no
tool is going to be able to tell you that.
> |> 2. Interruptible -a builds (i.e. portupgrade -af will restart from where
> |> it was last interrupted [perhaps with an additional flag?])
> |
> | Portmaster has this feature, you add the -R flag along with -f (or
> | -r). (Note, not all command line options mean the same thing for both
> | tools. Look at the man pages.) You can also use the -C flag to avoid
> | deleting what you've already built for ports in progress.
>
> This means you need to keep track of what top level ports you have
> installed in your head or in notes somewhere.
It wouldn't be a very useful feature if that were true, now would it?
You have a bad habit of speaking authoritatively about things you
don't actually know. It would help a lot if you did a little leg work
to test your assumptions first.
In this case, portmaster actually keeps track of what has been built
already for you, so all you'd need to do is 'portmaster -Raf' and it
would skip things it built in the last run(s). Once the -f (or -s) run
is successful, it deletes the flag files that indicate something is
already rebuilt.
> Also in reading the man
> page for portupgrade I do not see how -C does what you say it does
I said read the man pageS, and specifically pointed out that some of
the option names are different. The sources for the script and the man
page for portmaster are in the tree, you can look at them without even
having to install them if you want to.
> |> Also two behaviours that make no sense to me:
> |>
> |> 1. When doing portinstall and/or portupgrade -af on a large set
> |> dependant ports (such as xorg) the default options get built *BEFORE*
> |> the option screen is displayed. For example when doing xorg-drivers
> |> nv, ati/radeon/i810 are built before it asks you what drivers to build.
> |
> | Portmaster runs through all the options dialogs first (and downloads
> | new distfiles in the background), then starts the building process.
>
> Does it also check for conflicting options at that time?
How is portmaster supposed to know what "conflicting" means? :)
Seriously though, I have talked about my idea for "super-options" that
if set could influence the options for other ports, but we don't have
that yet.
Doug
--
This .signature sanitized for your protection
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47B4B6A0.6090200>