Re: Looking for speed increases in "make index" and pkg_version for ports





On Wed, 30 May 2007, Bakul Shah wrote:

Peter Jeremy <peterjeremy@xxxxxxxxxxxxxxxx> wrote:
On 2007-May-27 16:12:54 -0700, Bakul Shah <bakul@xxxxxxxxxxxxx> wrote:
Given the size and complexity of the port system I have long
felt that rather than do everything via more and more complex
Mk/*.mk what is is needed is a ports server and a thin CLI
frontend to it.

I don't believe this is practical. Both package names and
port dependencies depend on the options that are selected as
well as what other ports are already installed. A centralised
ports server is not going to have access to this information.

I didn't mean a centralized server at freebsd.org but on your
freebsd system and can know about what ports are installed.
Conditional dependencies have to be dealt with. Perhaps the
underlying reason for changing package names can be handled
in a different way.

What happens now is that mostly static information from
various files is recomputed many times. While that can be
handled by a local database, it seems to be a daemon provides
a lot of benefits.

Come to think of it, even a centralized server can work as
there are a finite number of combinations and it can cache
the ones in use. But all this is just an educated guess.

Your idea really looks very fine to me. From reading other emails on this thread, I get the impression that a lot of the underlying work has already been done in perhaps the portupgrade port, and so all you would have to do is to provide an interface from the make file to the database produced by portupgrade. Perhaps this could be made conditional, so that those who don't install portupgrade wouldn't use it. Even so, I also get the feeling that to implement this would be quite some work, so a volunteer needs to step forward. But my gut reaction is that this is almost certain to make things like "make clean" and pkg_version way way faster.

And I must admit that I am having more doubts about my "calculate the variables just in time" idea. The thought of working really hard to make it work, and then seeing mediocre speed increases is rather offputting to me.

_______________________________________________
freebsd-hackers@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"



Relevant Pages

  • Re: subversion on FreeBSD 4.10
    ... I've upgraded all the ports including perl. ... # CFLAGS controls the compiler settings used when compiling C code. ... # or supported for compiling the world or the kernel - please revert any ... # To avoid running MAKEDEV all on /dev during install: ...
    (freebsd-questions)
  • Re: newest PHP port upgrade broke php5-mbstring-5.0.1 ?
    ... # CFLAGS controls the compiler settings used when compiling C code. ... # or supported for compiling the world or the kernel - please revert any ... # certain ports. ... # To avoid running MAKEDEV all on /dev during install: ...
    (freebsd-questions)
  • Re: building thunderbird port on v. 4.9
    ... > it happens when the user instructs the ports system to forceably ... > deinstall all files installed by a package, ... > portupgrade, it correctly preserves the old library version. ... Let us say i wanted to install wxpython. ...
    (comp.unix.bsd.freebsd.misc)
  • Re: cvsup and portupgrade
    ... > source and ports. ... > appropriately, make deinstall, the cvsup the ports, then make install) ... > I've heard reference to a portupgrade package, ...
    (freebsd-questions)
  • Re: So How Hard Is Moving From 6.3 To 7.0?
    ... you can install the misc/compat6x ... a few hours of watching compiler output scrolling up your screen ... you are updating all your ports. ... in your face if you just naively run 'portupgrade -fa'. ...
    (freebsd-questions)