portindex -- the second coming.

[Matthew Seaman]

On Mon, Nov 01, 2004 at 11:11:23PM +0000, Matthew Seaman wrote:
> On Mon, Nov 01, 2004 at 12:13:55PM -0800, Kris Kennaway wrote:
> > On Mon, Nov 01, 2004 at 08:01:16PM +0000, Matthew Seaman wrote:
> > > On Mon, Nov 01, 2004 at 11:12:17AM -0800, Kris Kennaway wrote:
> > > > On Sat, Oct 30, 2004 at 11:51:07PM +0100, Matthew Seaman wrote:
> > > > 
> > > > > Slightly later than planned (real life getting in the way I'm afraid),
> > > > > here's the third (and I hope final) beta version:
> > > > > 
> > > > >     http://www.infracaninophile.co.uk/portindex/portindex-0.3.tar.bz2
> > > > > 
> > > > > This incorporates various bug fixes and feedback from earlier versions.
> > > > 
> > > > I took a quick look at the code, and it doesn't look like you track
> > > > .included files.  This is important, because changes to
> > > > e.g. <bsd.kde.mk>, or "../../othercategory/otherport/Makefile.inc" can
> > > > change the result of 'make describe' of the port, and therefore the
> > > > resulting INDEX.
> > > 
> > > Good point.  Very good point -- now why didn't I see that, dammit?
> > > Aha!  Hidden away at the end of the make(1) man page:
> > > 
> > >     make -V .MAKEFILE_LIST | tr \  \\n
> > 
> > You probably want to strip out the stuff in /usr/share/mk which should
> > not have any impact on port dependencies, but to be strict you should
> > treat changes to /etc/make.conf and bsd.port.mk as requiring a rebuild
> > of the full index.  bsd.sites.mk can be ignored too.
> 
> Absolutely.  Some Makefiles are included everywhere, and if they get
> modified, the best thing to do is rebuild the cache from scratch.
> Checking for modifications to /etc/make.conf: that's not something I'm
> going to catch by parsing cvsup output.  I guess I'll just have to put
> in a catch-all that looks at the timestamp of that file and any other
> likely suspects and that will trigger a message recommending general
> rebuild of the cache.
>  
> > Also you need to think about the case of variables being set in the
> > environment but not in make.conf - either you have to recognise them
> > somehow (difficult), or (better) you have to build the index with a
> > clean environment since otherwise you'll get undefined results
> > (e.g. if someone does a partial update after having set WITHOUT_GNOME
> > in the environment of that shell, they'll get a wacky index that may
> > not be self-consistent).
> 
> This I think is really the user's problem.  If they habitually set
> 'WITH_FOO' in their environment while building ports, then building or
> updating an INDEX file should include the effects of WITH_FOO.
> Documenting that changing significant environment settings really does
> require reinitialising the cache is clearly necessary.
> Hmm... although an option to turn on scrubbing the environment is
> certainly a good idea as well.
> 
> > There's also the problem of ports that auto-detect their dependencies
> > based on installed files; this is difficult to solve because the
> > trigger is some random file on the system.  If someone builds index,
> > installs such a 'trigger port', and then does an index update, their
> > incremental index won't be the same as if they rebuild it from
> > scratch.
> 
> Now this I really can't do anything about.  Sometimes it will take
> human intervention to recognise when it is necessary to reinitialise
> the cache from scratch, or to force an update of the cached data for
> certain ports.  I think this is something I'll just have to get people
> to give me feedback on, as I have no idea how often it will be run
> into in practice.  On the other hand, having a slightly inconsistent
> INDEX file is not actually a disaster, and chances are many people
> wouldn't even notice the problem.

I've now incorporated the changes Kris suggested as far as possible.
The latest version is at:

    http://www.infracaninophile.co.uk/portindex/FreeBSD-Portindex-1.1.tar.bz2

I'll be submitting this as a port in the very near future.

Please do send me any comments, bug reports etc.  I'll try and deal
with them as promptly as possible -- unfortunately that may not be
quite as promptly as I'd like since real life -- in the form of a new
job -- will definitely be getting in the way from the middle of next
week onwards.

	Cheers,

	Matthew

-- 
Dr Matthew J Seaman MA, D.Phil.                       26 The Paddocks
                                                      Savill Way
PGP: http://www.infracaninophile.co.uk/pgpkey         Marlow
Tel: +44 1628 476614                                  Bucks., SL7 1TH UK
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20041105/1f3b5912/attachment.bin