This is a discussion on Re: Evolution crawls on FreeBSD - FreeBSD ; Quoting Joe Marcus Clarke (from Sun, 02 Mar =20 2008 19:31:34 -0500): Summary: the patch in the PR is not at production quality, I =20 understand the portmgr decision, ideally the rejection reason (by Ade =20 and/or portmgr) in the ...
Quoting Joe Marcus Clarke
(from Sun, 02 Mar =20
2008 19:31:34 -0500):
Summary: the patch in the PR is not at production quality, I =20
understand the portmgr decision, ideally the rejection reason (by Ade =20
and/or portmgr) in the PR should have been more detailed.
A long and more detailed answer with improvement suggestions is below...
> On Mon, 2008-03-03 at 00:12 +0100, Jean-Yves Lefort wrote:
>> I suspect that the patch in this PR would have greatly helped:
>> Indeed, a casual inspection of libexec/rtdl-elf/rtld.c shows that the
>> SO_NEEDED lists (Obj_Entry.needed) are walked recursively. Removing
>> the useless entries might therefore have a dramatic impact on
> This is what mezz suspected as well, and I believe he will test this.
As already told to him today in a private discussion: Adding only this =20
patch will not help much (at least it will not directly result in the =20
ideal solution). I experimented with a different patch. My patch =20
changes libtool directly (I discussed this with the libtool =20
maintainers, libtool 1.5 has problems with static linking and maybe =20
cross-compiling when this is done, that's the reason why it is not =20
enabled by default in Linux, Debian has a patch and enables it itself, =20
but this is not sanctioned by the libtool maintainers, libtool 2.0 is =20
supposed to solve the problem, my patch to libtool 1.5 should not be =20
applied, as it will break libtool in a few cases).
The result of the patch is, that some libs are not added. This is =20
good. But a lot of ports (X libs, cairo, pango, gtk, ...) add the libs =20
on the link command line, so that those libs get added, even if they =20
are dependencies which can be resolved recursively. To solve this, the =20
corresponding ports need to be changed. Ideally this should happen =20
upstream. pkg-config has support for this (private_libs or something =20
like this), but in a lot of packages this is not used yet. The right =20
fix for this software is to add the indirect dependencies to those =20
private libs stuff in the pkg-config part. When libtool 2.0 hits the =20
tree and is adopted, the problem should vanish then (and we could =20
switch to explicit package dependencies, it would cut down a lot the =20
number of ports to recompile in some situations).
>> Unfortunately, the affected maintainer has closed the PR, mainly
>> because he could not understand it. And portmgr has backed the
>> maintainer, mainly because of personal friendship.
> We did not side with ade out of friendship. We had to weigh the benefit
> of this patch against the benefit of having a dedicated autotools
> maintainer. Since autotools is quite complex, but very critical to a
> large number of ports, and since we didn't have people lining up to be
> autotools maintainers, we opted to respect ade's maintainership of
> libtool, and his decision. I don't think you would like it very much if
> portmgr told you that you had to commit something to a port that you
But I don't mind if portmgr ask me in such a situation for more =20
details regarding the rejection.
Just by looking at the PR (and knowing about the public mails between =20
Ade and jylefort) it _looks_ like Ade has no idea what he is talking =20
about for this particular patch. If he would have added some more =20
words why he thinks that the patch is not ok, then it would look =20
differently. So I can understand the reaction of jylefort.
Note, as you can see above, I talked with the libtool maintainers and =20
know the drawbacks of the patch in the PR. It can only be applied to =20
dynamic libs. Static libs and some cross-compiling situations should =20
not be handled with this (personally I would suggest an opt-out knob, =20
but as the patch will not be imported...). In general I don't see =20
major showstoppers for something like this (if libtool itself is not =20
modified), but it will not be as easy as just adding this patch. I =20
expect several experimental port builds and adding of e.g. the above =20
mentioned opt-out knob to some ports, until the patch is at production =20
> Personally, I like your patch. I was a big supported (and user) of
> ltverhack as well. There are quite a few things I would like to see
> committed to FreeBSD (e.g. this patch, pthread changes, etc.) but I have
> to respect the wishes of the maintainers of those subsystems as I could
> not, nor would not be able to, do a better job.
I can understand your motivation. I don't object to your decision. =20
Nothing I write above is meant to be rude or force someone to do =20
something (just in case someone got up with a bad mood today).
Kiss your keyboard goodbye!
http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "email@example.com"