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

[Alexander Leidinger]

On Wed, 28 Jan 2004 18:06:32 +0900
Alexander Nedotsukov <bland at freebsd.org> wrote:

> 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.

You can miss explicit dependencies the way it works ATM too. And I'm
sure bento will tell you about major mistakes. I don't think this
results in major work. Maybe a shift in the focus of what's important to
do, but once you converted everything should just work as it already
does.

>     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).

And you may not know without reading the source if a port makes direct
glib calls or not. What about a pragmatic approach: let the maintainer
decide if glib needs to get included or not.

Think about libgnomeui. It depends upon gtk and it isn't possible to use
libgnomeui without gtk, but a program may also use some gtk widgets and
not only libgnomeui widgets. If the maintainer decides he only needs to
depend upon libgnomeui then it's ok. If later someone gets bitten by
this, just add the dependency. In the short term this may result in a
little bit rough experience with the ports tree, but in the long term
you will "know" when to add a dependency and when not. In the mid term I
expect the quality of the ports collection to increase and nobody will
care about one or two more lines in the makefile.

>     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.

Provide a switch in make.conf to choose the desired behavior, post a
heads-up with a timeframe when we want to switch over to the new world
order, let the PRs and commits flow in (it doesn't hurt to have a
dependency implicitly and explicitly at the same time).

When it's time to switch have a look at the ports collection, if you see
a continues flow of work happen slide the date of the switch to the new
world order as you think is best, if the number of new world order
commits are on the falling edge just switch over and see more commits
because of complaints.

I don't expect the switch to be smooth, but I expect it to not be rough.

Bye,
Alexander.

-- 
           I will be available to get hired in April 2004.

http://www.Leidinger.net                       Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7