Date: Thu, 20 Mar 2008 12:57:02 -0700 From: Doug Barton <dougb@FreeBSD.org> To: "Sean C. Farley" <scf@FreeBSD.org> Cc: freebsd-ports@FreeBSD.org Subject: Re: Utility for safe updating of ports in base system Message-ID: <47E2C18E.7060208@FreeBSD.org> In-Reply-To: <alpine.BSF.1.10.0803200943480.3756@thor.farley.org> References: <20080320001048.GA39125@lpthe.jussieu.fr> <alpine.BSF.1.10.0803200047360.54264@ync.qbhto.arg> <alpine.BSF.1.10.0803200943480.3756@thor.farley.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Sean C. Farley wrote:
> On Thu, 20 Mar 2008, Doug Barton wrote:
>
>> On Thu, 20 Mar 2008, Michel Talon wrote:
>>
>>> In my opinion, an example of a correct "pkg_upgrade" type programm
>>> written in C++ is the Debian apt-get. It works predictably, fast,
>>> etc. One of its features, that i consider very important for correct
>>> operation, is that it computes the list of all packages to be deleted
>>> and all packages to be installed and asks the user if he agrees
>>> before doing anything.
>>
>> Why do you consider this an important feature? (I'm not disagreeing,
>> just curious about your thought process here.)
>
> Personally, I like to know everything that will happen before it
> happens. When options change, I am not always sure what it will bring.
> For example, I do not have HAL (WITHOUT_HAL via portconf) installed on
> my system. Some ports may try to bring it in regardless of the setting;
> I would like to see that first. In this case, I think portmaster -na
> gives me an idea of what will happen.
Yeah, especially now that the -n option actually runs everything all
the way through the configure phase. You've touched on one of the
things that makes this task difficult though, it's impossible to
really know what's going to happen until the user has actually gone
through the configure options, which could add or delete entire trees
of the dependency graph.
This also brings up one of the things I'd like to see improved about
our OPTIONS, the idea of "super options" that I posted a while back.
This would allow a port for whom HAL support is mandatory (for
example) to toggle it on by default for all other ports for whom it's
relevant, ideally with some sort of notification about why it's on by
default.
Doug
--
This .signature sanitized for your protection
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47E2C18E.7060208>