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

[Pav Lucistnik]

Alexander Leidinger píše v út 04. 09. 2007 v 13:13 +0200:

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

But not in the beginning. Say, make depends target will get very slow
and very chatty after your changes.

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

You are operating on false assumptions here. Let me explain how libtool
on FreeBSD work. It explicitly passes all indirectly required libraries
to the linker during build. So they all get recorded in the shared
library files and in the binaries. Will show up on your script.
Needlessly. The reason is that Linux needs it - Linux does not do
indirect library loading in rtld.

That's also why you see so much garbage in pkg-config files.

> Is this a valid argument now? Not at all. Feel free to complain later
> when you see numbers, but not now.

I'd love to see the numbers.

> I also want to point out that with explicit dependencies, we can
> switch the ports collection into recording only explicit dependencies
> in packages.

Here you are proposing to turn off one of the basic features of the
ports system. I think people would be quite unhappy if they would need
to list all the indirect dependencies on all the p5 modules in their
ports, for example.

This will never happen.

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

You failed to address my concern about the frequency of major changes
like that, compared to all the extra work imposed on all the porters.

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

You basically talked long time about all the advantages you see, failing
to address my two concerns: additional machine overhead, and additional
maintainer overhead.

I don't want to get into discussion about the implementation details of
your idea.

> 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

It does, in fact. The symbols is not everything. It can be passing
around and modifying a data structure created by libpng, which could
change on png upgrade.

It's better be safe than broken. libpng major upgrades does not happen
that often.

-- 
Pav Lucistnik <pav at oook.cz>
              <pav at FreeBSD.org>

What do you mean? An African or a European swallow?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: Toto je =?UTF-8?Q?digit=C3=A1ln=C4=9B?=
	=?ISO-8859-1?Q?_podepsan=E1?= =?UTF-8?Q?_=C4=8D=C3=A1st?=
	=?ISO-8859-1?Q?_zpr=E1vy?=
Url : http://lists.freebsd.org/pipermail/freebsd-gnome/attachments/20070904/ea385edd/attachment.pgp