Date: Tue, 7 Aug 2007 22:24:15 +0200 From: Alexander Leidinger <Alexander@Leidinger.net> To: Peter Jeremy <peterjeremy@optushome.com.au> Cc: cvs-ports@freebsd.org, cvs-all@freebsd.org, ports-committers@freebsd.org Subject: Re: cvs commit: ports/Mk bsd.port.mk Message-ID: <20070807222415.4887a05d@deskjail> In-Reply-To: <20070807184011.GN1224@turion.vk2pj.dyndns.org> References: <20070803125410.GB1062@tirith.brixandersen.dk> <200708032144.57558.lofi@freebsd.org> <20070803204215.GA68620@rot26.obsecurity.org> <20070806074318.q9mw6ulngg00gwsw@webmail.leidinger.net> <20070806065634.GA31676@rot26.obsecurity.org> <20070806113855.0fcq213io0www04k@webmail.leidinger.net> <46B7072E.8070307@freebsd.org> <20070807111509.ojm8nc4ao0g080ck@webmail.leidinger.net> <46B84C78.3030009@freebsd.org> <20070807145123.yb3dqjojk08s40wg@webmail.leidinger.net> <20070807184011.GN1224@turion.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Peter Jeremy <peterjeremy@optushome.com.au> (Wed, 8 Aug 2007 04:40:11 +1000):
> On 2007-Aug-07 14:51:23 +0200, Alexander Leidinger <Alexander@Leidinger.net> wrote:
> >ports. But for some ports you can get the benefit immediately. I hope you
> >are not too biased regarding KDE. Yes, KDE and such would benefit by a huge
> >amount by this, more than smaller ports, but even for the "small"
> >dependency trees this can result in nice improvements.
>
> I can see the speed advantage in your suggestion: Modular X has
> definitely resulted in massive bloat in dependencies with simple X
> clients needing 60-70 dependencies. This is _very_ noticable when
> registering a package on a slow system.
>
> I'm less convinced that it is possible to automate the process.
I don't think you can automate it completely, but you can cover the
common case.
> >A list of libs for the given binaries:
> >---snip---
> >#!/bin/sh
> >
> >for i in "$@"; do
> > objdump -x "$i" | grep NEEDED | awk '{print $2}'
> > shift
> >done | sort -u
> >---snip---
>
> This won't detect dynamically loaded libraries. mplayer appears to
> dlopen() codecs. Further investigation might reveal other examples.
I'm aware of this. If I haven't wrote something about it my apologies,
I had to write the mail two times to get it out ones and may have
missed it in the second writeup. Often this is used for optional stuff
or plugins. So this case may be in the other way around (plugin ports
typically depend upon the port which uses dlopen to open the plugins,
not the other way around... you can not cover all edge cases).
> >Putting the XORG problem aside, I think you assume there is more work
> >required than will be necessary. I think there will be a lot work required
> >in the beginning (if a maintainer wants to improve immediately on his own,
> >but then he is responsible for his own time management), but then it is not
> >that much work.
>
> My concern is that this is all manual effort and, so far, I haven't seen
> anything that would let (eg) pointyhat automatically verify that the
> dependency chain is correct. Given the situation where A depends on B
Currently it also does not verify that the dependency chain is correct.
And the entire dependency chain is totally unchanged with what we are
talking about. We just not record every dependency in +CONTENTS and
+REQUIRED_BY anymore, only those which are referenced directly in the
binaries of the current port.
> depends on C but the Makefile for A does not list C as a direct dependency,
> how does pointyhat verify this is correct?
This should be part of the pointyhat build infrastructure, not of
bsd.port.mk. I'm not sure if it is a hard requirement to have this (I
have to think a little bit about Kris' recent mail before I decide what
my personal opinion about this is). I agree that it would be very nice
to have this.
Bye,
Alexander.
--
HELLO, everybody, I'm a HUMAN!!
http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070807222415.4887a05d>