Re: Why did autoconf deps change? Leads to xrender and pango problems?

"Tabitha McNerney" <[email protected]> writes:
>As I pull my hair out trying to figure out why the xrender port has
>recently
>given me problems (at first thinking it had to do with Xcode, Intel, Mac
>OS
>X Server 10.4.7 UB, etc., etc.) I have noticed something subtle. Even with
>DarwinPorts (MacPorts) 1.3.1 ... after I install it from source and then
>perform a:
>
># port -d selfupdate
>
>followed by a:
>
># port -v sync
>
>I notice that something has changed recently to autoconf, specifically
>autoconf states that it needs perl5.8 as a dependency. But this was not
>always the case. DP 1.3.1 (and also performing a selfupdate and sync from
>August 1st 2006), autoconf at that time did not require perl5.8, very
>specifically we have somehow gone from:
>
>port deps autoconf
>autoconf has no dependencies
>
>
>to:
>
>port deps autoconf
>> autoconf has runtime dependencies on:
>>         perl5.8
>>
>
>
>The question is why.

I did that.  There was an open bug on it and I checked the FreeBSD ports
system and checked FreeBSD and they have autoconf depending on perl as
well so I commited the change.

http://bugzilla.opendarwin.org/show_bug.cgi?id=7419

If that was not a right choice for DP then someone please say so and I'll
back out the dependency change and mark the bug as invalid.

>And further, I wonder if this caused a perturbation in
>the dependency chain that leads up to the xrender port that has caused me
>nightmares the past several days? Specifically:
>
>port deps xrender
>> xrender has library dependencies on:
>>         XFree86
>>         render
>>
>
>to:
>
>port deps XFree86
>XFree86 has build dependencies on:
>        perl5.8
>
>
>And now for whatever perl5.8 has itself been shuffled in the dependency
>chain, I can't help but wonder if this part of the problem that I have
>been
>observing with xrender.
>
>xrender is quite important to other ports in the dependency chain. For
>example, I saw complaints about pango. Well, if we do a trace, look at
>this:
>
>$ port deps pango
>> pango has library dependencies on:
>>         glib2
>>         XFree86
>>         Xft2
>>         cairo
>>
>
>which leads to ...
>
>$ port deps Xft2
>> Xft2 has library dependencies on:
>>         pkgconfig
>>         zlib
>>         xrender
>>         freetype
>>         fontconfig
>>         expat
>>
>
>
>Is there any reason why MacPorts / DarwinPorts 1.3.2 can not revert back
>to
>its state on 1 August 2006? At that time I had no problem building xrender
>(and pango for that matter) on both PowerPC but had not tried at that time
>on Intel hardware. However, earlier in the year I was fooling around with
>DP
>(I think it was version 1.2.1) on Intel but building to an HFS disc
>volume.
>The file system does not matter however (as I have proven by building tons
>of ports on UFS on PowerPC hardware).
>
>These are the war stories of mere mortals like we that Steve Jobs doesn't
>speak of in his charismatic Keynote presentations! But I can assure that
>gluing tons of open source to a quasi open source platform that is
>undergoing hardware architecture changes creates just what we should
>expect
>-- lots of stress :-)
>
I don't see that the problem you are experiencing has much to do with the
degree to which the Mac OS can be considered open source.  Probably the
most freqently used term that appears next to "open source" (besides the
term "free") is the term "community".  We are using community resources
and the changes we make affect others.  But the answer isn't to cease
making changes (and therefore progress) but to be open minded and
adjudicate the changes that occur (or that people want to occur) such that
the community interests are best served.  We figure this out by examining
bug reports and list messages and bargaining with each other and such. 
Which is to say, being a part of a community almost by definition brings
on a type of stress that comes about when changes occur over which we have
no control.  But I think the alternatives are worse in every way but
perhaps one.

Mark