portindex -- the second coming.

[Matthew Seaman]

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.

	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/20041101/596ee606/attachment.bin