Problems with ".if HAVE_GNOME" tests because of installation order

[Alexander Nedotsukov]

Alexander Leidinger wrote:

>On Tue, 27 Jan 2004 00:14:35 +0900
>Alexander Nedotsukov <bland at 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.
>
>  
>