portupgrade ideas page

Jeremy Messenger mezz7 at cox.net
Wed Jun 7 12:14:44 PDT 2006


On Tue, 06 Jun 2006 22:17:32 -0500, Kris Kennaway <kris at obsecurity.org>  
wrote:

> On Wed, Jun 07, 2006 at 10:39:50AM +0800, Jiawei Ye wrote:
>> On 6/7/06, Kris Kennaway <kris at obsecurity.org> wrote:
>> >> If all customizations are to be done in make.conf, what is the point
>> >> of MAKE_ARGS in pkgtools.conf?
>> >
>> >Flexibility, it's not supposed to be the primary means of customizing
>> >your ports, that's make.conf's job.
>> >
>> >Kris
>> Eh, not supposed to be? I have to admit that this idea of
>> "correctness" is new to me.
>
> It's "correct" in the sense of "this is the way it was designed to
> work".  portupgrade relies on the INDEX for computing dependencies,
> and the INDEX is a ports collection construct that uses ports
> collection resources including make.conf.

The portupgrade always work without INDEX. My INDEX is empty and I never  
need it.

# ls -l /usr/ports/INDEX.dummy
-rw-r--r--  1 root  wheel  0 May 20  2003 /usr/ports/INDEX.dummy

# make -V PORTS_INDEX
/usr/ports/INDEX.dummy

The portupgrade's pkgversion will not work without INDEX, but I prefer to  
use pkg_version instead.

Cheers,
Mezz

>> I have been using portupgrade since it
>> came into the ports tree. One thing I like about the
>> portupgrade/portmanager style of managing ports make_args is that they
>> provide a very simple syntax for specifying per-port args.
>> '<portname>'=>'arg1 arg2.....' (portupgrade style)
>> <portname>|arg1 arg2 arg3| (portmanager style)
>>
>> Does make.conf provide such syntax? Last time I read from the ML, one
>> needs the {curdir} magic boiler plate for that. It is hard on the eyes
>> and reduces useful information on a 80x25 console IMHO.
>
> The latter.
>
> Kris


-- 
mezz7 at cox.net  -  mezz at FreeBSD.org
FreeBSD GNOME Team
http://www.FreeBSD.org/gnome/  -  gnome at FreeBSD.org


More information about the freebsd-ports mailing list