ports/115870: [DEPS] graphics/cairo reduce X dependencies

[Jeremy Messenger]

On Tue, 04 Sep 2007 06:13:05 -0500, Alexander Leidinger  
<Alexander at Leidinger.net> wrote:

> Quoting Pav Lucistnik <pav at FreeBSD.org> (Tue, 04 Sep 2007 11:59:19  
> +0200):
>
>> Alexander Leidinger píše v út 04. 09. 2007 v 11:46 +0200:
>> > Quoting Pav Lucistnik <pav at FreeBSD.org> (Tue, 04 Sep 2007 11:18:10  
>> +0200):
>> >
>> > > Alexander Leidinger píše v út 04. 09. 2007 v 11:11 +0200:
>> > >
>> > > > > What do you mean by 'explicit' depends? I don't want to list  
>> every
>> > > > > single each lib in every single each port, when I can rely on  
>> indirect
>> > > > > dependencies via ports like gtk20.
>> > > >
>> > > > Explicit dependencies makes it more easy to just rebuild those  
>> ports
>> > > > which use a specific lib which just had an ABI change. Our users  
>> want
>> > > > this.
>> > >
>> > > Ah, this nonsense again.
>> >
>> > Please explain why.
>>
>> You are adding a massive overhead on a day-to-day operation, like
>> calculating a dependency list, to solve a problem that only appears few
>
> Those ports show up in the dependency list anyway, as we are in the
> implicit dependencies mode. And there's a optimization in the
> bsd.port.mk dependency list creation, ports which are seen already are
> not taken into account again. See below.
>
>> times a year. Did you any benchmarks on what happens if you replace,
>> say, gtk20 with it's explicit dependencies, is all ports that define
>> USE_GNOME=gtk20?
>
> I don't add the explicit dependencies of gtk20 to all port which use it
> (the dependencies of gtk20 are implicit dependencies, when they are not
> linked into the executable of a port which depends on them). I just add
> the explicit dependencies. Not all libs which are recorded as needed in
> libA have to be added to a lib or binary of port B which depends upon
> libA. Only those libs which are specified on the gcc command line at
> link time for the binaries/libs of port B.
>
> Given a dependency tree like this:
> A -+-----+
>     \     \
> B ---+- C -+- D
>
> In this case D gets dependencies for A and C, but not for B. C gets
> dependencies for A and B.
>
> I just checked the output of "pkg-config --libs gtk+-2.0". It lists
> some superfluous libs. Most of those libs are already recorded as
> dependencies in libgtk-x11-2.0.so, so some of them can be removed. I
> think it is a bug to list libs which are not needed by a program which
> uses the gtk lib (AFAIK the GTK API doesn't contains symbols from those
> other libs, so a program doesn't need to link to them). I have a look
> at this.

It sounds like in ports/104877 ?

...and Pav is right about that we won't accept FreeBSD specific hackery on  
installed .pc files unless it is complete broke and a must to hack. Right  
way to do is to send your hacks to the upstream. We have been work hard on  
remove the FreeBSD specific hack, same as with what ade is doing with  
libtool/auto*.

Cheers,
Mezz

> No, I don't have benchmarks yet, as I just converted a few ports.
>
> If the ports A and B have more dependencies (which is common for leaf
> ports in the GNOME subtree), the optimization in bsd.port.mk doesn't
> look at dependencies of A more than once.
>
> Will there be a difference in benchmarks? Probably.
>
> Will the difference be significant? I don't know. Probably noticeable
> but not critical.
>
> Is this a valid argument now? Not at all. Feel free to complain later
> when you see numbers, but not now.
>
> I also want to point out that with explicit dependencies, we can
> switch the ports collection into recording only explicit dependencies
> in packages. The infrastructure is available (a switch exists). This
> will speed up the package-dependency list creation (no need to recurse
> anymore, this will be a huge speedup for leaf ports in GNOME and KDE).
>
>
> Result of this part of your complaint: there's a problem, but the
> solution is not to forget about the explicit dependencies, but to fix
> the pkg-config files (continuing the work which was started by fixing
> libtool/libltdl). I will have a look at this after gnome 2.20 hits the
> tree.
>
>> Also, the new world order is lot less intuitive and transparent to the
>> porter. Hard to spot mistakes and ommissions will be made.
>
> I think the opposite is the case. A porter installs the port and runs
> the script. He will get a list of all libs which are linked to the
> binary _directly_. This should even result in less pointyhat failures
> because of missed libs.
>
>> Thirdly, what happens if, say, gtk20 grows a dependency on a new X
>> library? You will go and add it to all the thousands of individual
>> ports?
>
> No, see above. As the linker is able to recursively resolve libs, only
> direct dependencies need to be listed. If port A directly uses symbols
> from libB (if nm(1) lists them in the binary), a dependency has to be
> added.
>
>> > Would you please provide technical details why you are opposed to lift
>> > the Ports Collection to a higher feature/quality level?
>>
>> I don't think this moves the ports to a higher quality level, quite the
>> opposite.
>
>  - less ports to compile on major changes
>  - less work to do (scripts for bumping port revisions and listing
>    the lib dependencies exist in the Tools/scripts directory), see
>    below for more on this
>  - less pointyhat failures because of missed libs
>  - better oversight of the impact of major changes
>  - more automatisms
>  - the explicit dependency script can even be integrated into
>    pointyhat runs to do an additional correctness check, we have
>    nothing like this and Kris was happy to see a script which lists
>    the libs which are needed by a port because of a problem which
>    manifested on pointyhat
>
>> You are basically committing to do a lot of tedious manual work, which
>> is currently done by the framework, just because you think you can do
>> that job marginally better.
>
> You have to list libs anyway. Instead of thinking a lot about which
> libs need to be added (sometimes this is trial and error, sometimes it
> is an educated guess), run the script and copy&paste the _real_
> dependencies. I fail to see where this increases tedious manual work. I
> would say it decreases tedious manual work.
>
> Note, I also plan to write a script which compares the list of libs
> references by an installed port with the LIB_DEPENDS recorded in the
> Makefile.
>
>> I don't buy that.
>
> Do you have some more things I should comment upon? So far I think I
> presented technical arguments which show that your concerns can be
> taken care of in a good way.
>
>> Your claws example can be solved by only bumping ports that
>> build_depends on python on next python upgrade.
>
> For claws and python: yes.
> But this was just an example. Maybe not a good one. Please think about
> the big picture. A port which doesn't use any symbol of png directly,
> but just uses the gtk functions which use png internally, doesn't need
> to be rebuild on a png change, as there should be no reference to the
> png lib in the binary (as already told, I think it is a bug in e.g. the
> gtk pkg-config data to list the png and some other libs; I will look
> into this).
>
> Bye,
> Alexander.


-- 
mezz7 at cox.net  -  mezz at FreeBSD.org
FreeBSD GNOME Team  -  FreeBSD Multimedia Hat (ports, not src)
http://www.FreeBSD.org/gnome/  -  gnome at FreeBSD.org
http://wiki.freebsd.org/multimedia  -  multimedia at FreeBSD.org