Date: Tue, 4 Sep 2007 15:38:44 +0200 From: Alexander Leidinger <Alexander@Leidinger.net> To: pav@FreeBSD.org Cc: gnome@freebsd.org Subject: Re: ports/115870: [DEPS] graphics/cairo reduce X dependencies Message-ID: <20070904153844.41fb9423@deskjail> In-Reply-To: <1188906263.28297.160.camel@pav.hide.vol.cz> References: <200709032101.l83L1qr1018167@freefall.freebsd.org> <20070904000756.756b72fc@deskjail> <1188894171.28297.82.camel@pav.hide.vol.cz> <20070904111144.6c3fb68c@deskjail> <1188897490.28297.129.camel@pav.hide.vol.cz> <20070904114601.48f36f42@deskjail> <1188899959.28297.148.camel@pav.hide.vol.cz> <20070904131305.25c46cc8@deskjail> <1188906263.28297.160.camel@pav.hide.vol.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Pav Lucistnik <pav@FreeBSD.org> (Tue, 04 Sep 2007 13:44:23 +0200): > Alexander Leidinger p=C3=AD=C5=A1e v =C3=BAt 04. 09. 2007 v 13:13 +0200: >=20 > > > You are adding a massive overhead on a day-to-day operation, like > > > calculating a dependency list, to solve a problem that only appears f= ew > >=20 > > Those ports show up in the dependency list anyway, >=20 > But not in the beginning. Say, make depends target will get very slow > and very chatty after your changes. Increasing the number from e.g. 3 to e.g. 20 does not slow down that much, and when you look at the rest of the build (compiler runs) of e.g. mozilla or openoffice or some random GNOME/KDE port, I think the amount of chattyness is small. > > 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.=20 >=20 > 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 AFAIK it operated like this in the past, but not now anymore (it was one of the complains des(?) had with the autotools ports, it is not present in the old libtool versions, but AFAIK it is present in a recent libtool version). I will check this to make sure it works and come back to you with the result. > 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. AFAIK libltdl does it on linux, so for programs which use libltdl this is not necessary. And libtool resolves the list itself at runtime if necessary (for this reason the .la files are installed), so for programs where libtool is used, this is not necessary too. BTW: I just checked for gtk20 after my last mail. They have .pc files for the installed and uninstalled case. The uninstalled case lists the .la file in the build directory together with all dependencies. The installed case lists the compiler flags together with all dependencies. I'm in the process of testing the removal of the dependencies from the .pc file for the installed case. > That's also why you see so much garbage in pkg-config files. >=20 > > Is this a valid argument now? Not at all. Feel free to complain later > > when you see numbers, but not now. >=20 > I'd love to see the numbers. >=20 > > I also want to point out that with explicit dependencies, we can > > switch the ports collection into recording only explicit dependencies > > in packages. >=20 > 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. >=20 > This will never happen. And doesn't need to happen. I just wrote above to not list the indirect dependencies in the package (what ends up in +CONTENTS and in +REQUIRED_BY when installed). If you recursively install a package, all indirect dependencies will be installed too, so no need to list indirect dependencies (and no basic feature will be disabled). This also has not have to happen immediately, we first can run as we do now to get an idea how the explicit dependencies work out. > > > > Would you please provide technical details why you are opposed to l= ift > > > > the Ports Collection to a higher feature/quality level? > > >=20 > > > I don't think this moves the ports to a higher quality level, quite t= he > > > opposite. > >=20 > > - less ports to compile on major changes >=20 > 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 think I addressed this. Again: Any porter has to make sure he adds the right LIB_DEPENDS. And as we see from time to time this doesn't happen every time in the right way. With my script the porter just installs the port and runs the script. After that he has a list of good dependencies. > > > I don't buy that. > >=20 > > 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. >=20 > You basically talked long time about all the advantages you see, failing > to address my two concerns: additional machine overhead, and additional > maintainer overhead. Sorry, I fail to see that I didn't addressed additional maintainer overhead. I explicitly said it reduces maintainer overhead. He hasn't to care about the lib depends, as the script does the work for him. And additional machine overhead is an assumption of you. Yes, it takes a little bit of machine time (some seconds wall clock time ) to list all deps of a port with a lot of binaries. No doubt about this. But this is on the machine of the porter and reduces the amount of work the porter has to do. Adding a check if the real deps match with the deps in the Makefile (on pointyhat) is something which can be done afterwards, and would be a check which improves the quality of the ports (if we o the explicit way) and would be not a waste of machine cycles in my eyes. So the only part where there may be machine "overhead" is in the dependency stuff, but as already said, as long as we don't have numbers and can decide if they are significant off or not, you can not complain. From my testing of the speed improvements in the dependency parts of bsd.port.mk this year, I don't expect a difference which makes this a no-no. > I don't want to get into discussion about the implementation details of > your idea. >=20 > > 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 >=20 > 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. I fail to see where this is the case in gtk, but for the general case, yes, this may be possible. I expect the percentage of such problems to be very small (compared to >17000 ports). It can not be detected by my script. No doubts. But we are in this situation already. So what? We bump the revision of the corresponding port as soon as we know about it (like now) and the maintainer can add the port as a build or lib dependency (like it should be done now). My work is not supposed to solve this problem. It is supposed to solve a problem which affects a lot more ports. > It's better be safe than broken. libpng major upgrades does not happen > that often. Oh, come on, don't ride on the png lib. The gnome / kde / X11 libs change much more and benefit much more from this. And regarding the "better be safe than broken" part... we all know about the mails after a KDE/GNOME/X11/... update. So far there where bugreports all the time after a major upgrade. Some problems are because of missing dependencies, some are because of missed portrevision bumps. By listing the explicit depends you get rid of some complains (no missed libs, ability to check for more affected ports than now). And by adding a check-script to pointyhat runs, you can even get the big picture and are not limited to your local testing. My work doesn't help the small ports, but for the big frontline ports this will reduce the number of complains after a major update (not all complains, as there are cases where this will not help). Bye, Alexander. --=20 Hello? Enema Bondage? I'm calling because I want to be happy, I guess ... http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070904153844.41fb9423>