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

[Alexander Leidinger]

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.

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.

-- 
Not SENSUOUS ... only "FROLICSOME" ... and in need of DENTAL WORK ...
in PAIN!!!
http://www.Leidinger.net  Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org     netchild @ FreeBSD.org  : PGP ID = 72077137