Date: Wed, 28 Jan 2004 18:06:32 +0900 From: Alexander Nedotsukov <bland@FreeBSD.org> To: Alexander Leidinger <Alexander@Leidinger.net> Cc: Joe Marcus Clarke <marcus@FreeBSD.org> Subject: Re: Problems with ".if HAVE_GNOME" tests because of installation order Message-ID: <40177B98.8050606@FreeBSD.org> In-Reply-To: <20040127123558.7eacc6c5@Magellan.Leidinger.net> References: <20040126133927.26c8247b@Magellan.Leidinger.net> <40152EDB.70406@FreeBSD.org> <20040127123558.7eacc6c5@Magellan.Leidinger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Alexander Leidinger wrote:
>On Tue, 27 Jan 2004 00:14:35 +0900
>Alexander Nedotsukov <bland@FreeBSD.org> wrote:
>
>
>
>>Alexander,
>>
>>This is not gnome ports specific problem. Any port wich tries to guess
>>
>>
>
>But Gnome is a prominent example and shares a lot more developer
>resources than a maintainer of one of those non-gnome ports may be able
>to get help from.
>
>
>
>>it configuration in way ".if exists() xx_DEPENDS+=" have such flaw.
>>Situation can be resolved sometimes by adding WITHOUT_xx option if
>>
>>
>
>It helps if you don't want such behavior, but in cases where you don't
>want the WITHOUT_x one, this isn't helpful.
>
>
>
>>they supported by port (unfortunately this is not sysutils/cdrdao
>>case). The better way seems to use info stored in /var/db/pkg rather
>>than do recursive make wailk through ports tree but this I guess need
>>more than my pure speculation on subject :-)
>>
>>
>
>I think a port should only depend on it's explicit dependencies, not on
>the implicit ones. This implies, that a port should register every
>dependency explicitly and shouldn't rely on implicit dependency
>registrations.
>
>
You reading my mind :-)
>Did I overlooked a situation where this causes problems?
>
>
This implicit dependencies comes from current ports build system.
I raised this question once before and bellow a recap of that.
Let's start from disadvantages:
1. Explicit dependencies make maintainer life more difficult.
We will be required pay more attention to such dependencies. It's a bit
easy to do in
case of GNU autoconfed stuff by carefull reading configure.{in,ac}
files. But there is
no 100% guaranee that those files complete. For other ports complete
Makefiles
inspection will be required.
2. Makefiles expected to bloat.
It's easy to explain in a sample. A lot of ports not do not include glib
beacuse they
already include something wich depends on it. But nearly all of them
make explicit use
of some g_* (ie. g_malloc/free).
3. Switching over to new method will be extremly big and painful
process.
In theory such change will affect most of ports. I can't imagine how
such big task can
be done smooth in real life.
Advantages:
1. Get rid of false dependencies in /var/db/pkg.
This was duscussed under the subject.
2. Speed up of ports build framework.
I can count here on index and dependencies generation since they will
not require
recurrent walk through all Makefiles involved.
3. Shlib version bump processing simplified.
At the moment it's impossible to say what exactly need to be rebuild
after port shlib
version bumped. Common practice to call for portupgrade -rf in this
case wich is far
from optimal in cost of human and cpu time.
4. More clear pkg_info output.
+CONTENTS and +REQUIRED_BY will shrink/cleanup. And -r -R options
will show only explicit dependencies wich imho much more welcome to
see by user.
Old behaviour and/or more informative dependency tree view may be
implemented.
My feeling about all above is 50/50. It's difficult to say that this
idea is bad or
good. Perhaps more people involved in discussion give us better result?
All the best,
Alexander.
>Bye,
>Alexander.
>
>
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40177B98.8050606>