incremental ports/INDEX builder

Dan Langille dan at langille.org
Tue Jun 22 09:04:21 PDT 2004


On 22 Jun 2004 at 15:29, Oliver Eikemeier wrote:

> Mark Linimon wrote:
> 
> > On Tue, 22 Jun 2004, Kris Kennaway wrote:
> >
> >> That amounts to tracking .included files and
> >> updating that dependency list when it changes, since those are the
> >> corner cases that a straightforward implementation doesn't catch.
> >
> > Is this going to be a part of bsd.port.mk?  If so, I'd like to use
> > it to solve the FreshPorts/portsmon problem (that of knowing "what
> > is a slave port").  Both Dan and I are leaning more towards a
> > bsd.port.mk-based solution (since both of our codebases are already
> > set up to do that) than eik's outboard solution which a) would have
> > to be run in parallel, and a) also defines many more ports to be slave
> > ports than Dan and I consider to be "interesting".   e.g., there is
> > a certain set of Makevars that he and I are interested in, none of
> > which are affected by including e.g. the KDE include file.  Yes,
> > this means that some manual inspection needs to be done -- trading
> > off guaranteed completeness for speed.
> 
> I'm sorry that I have been unable to show you the script delivers
> exactly what you want.

Oliver: I've given you feedback on this privately but given the 
above, I feel I must repeat it here.  

> To find slave ports of a port you could do:
> 
>   awk -F\| -v MASTER="mail/qmail" '$1 == MASTER "/Makefile" {print MASTER " -> " $3}' $DEPENDSFILE
> 
> with a result of:
> 
>   mail/qmail -> mail/qmail mail/qmail-ldap mail/qmail-mysql mail/qmail-smtp_auth+tls mail/qmail-tls
> 
> 
> To find master ports, just do:
> 
>   grep '^[^/]*/[^/]*/Makefile|' $DEPENDSFILE |
>   awk -F\| -v SLAVE="mail/qmail-mysql" '$3 ~ "(^| )" SLAVE "( |$)" {sub("/Makefile$", "", $1); print $1}'
> 
> Result:
> 
>   mail/qmail-mysql
>   mail/qmail

It appears we have two different definitions of what a MASTER port 
is.  For FreshPorts, it's the port from which information, such 
PORTREVISION and PORTVERSION, is obtained.  This is different from a 
dependency.  An example: lang/php4 is the master port for 
www/mod_php4.

> (in this example you have to quote metacharaters in SLAVE, like 
>  SLAVE="mail/qmail-smtp_auth\\+tls", but that is an problem of
>  awk, not the database.)

It looks like I need to run depends.pl each time a master/slave 
relationship changes.  Otherwise, the output may be out of date.  
Running depends.pl takes a while.  This is something I have always 
tried to avoid with FreshPorts.  I prefer to get information via 
"make -V" whenver possible.  

The ports tree used by FreshPorts is not updated via cvsup.  It is 
updated directly via fetch as the commit email is processed.

> Besides, you have to feed the list of updated files to some script
> to update the debedency database, which won't work with a pure
> ake -V' solution.

Mark and I are not trying to solve the dependency issue.  We are 
addressing one narrow situation: MASTERPORT.  That is quite 
different.

> > If we do go down the bsd.port.mk-based solution, there are about
> > 40 ports that have to be patched to manually override the proposed
> > default logic in bsd.port.mk to generate these makevars.  These
> > ports' Makefiles are too convoluted for me to dare to try to rework
> > them as true masterports.
> 
> Tell me some names, and I will tell you what my script delivers. You 
> still owe me a sample where my script is wrong.

We appear to be solving two different problems here. Whether or not 
your script provides the correct answer for the problem you are 
solving is not the point.  Your script is one way to solve the 
MASTERPORT issue, but the bsd.port.mk solution is much simpler for 
what I need for FreshProts.

> > Here is what I am using at the moment.  I would really like to know
> > whether we think that this is something that belongs in bsd.port.mk
> > or not, and if so, if the variable names are OK.  If it is, I'll go
> > ahead and submit patches for the 40 ports.  If not, the 40 ports will
> > continue to be wrong on both portsmon and FreshPorts until some
> > (possibly significant?) reengineering is done.
> 
> I guess this patch is fine.

We disagree.  Your code is great.  I'm sorry it is not what I need 
for FreshPorts.  I'm sure it will be useful for other applications, 
just not this one.
-- 
Dan Langille : http://www.langille.org/



More information about the freebsd-ports mailing list