login
Search
hello all fbsd devs i want to know if there is a possibility to avoid current strict libraries linking .. i will explain myself for example .. i have installed 'gtk' (2.18) that depends on library 'libpng.so.5' (png) .. and i will upgrade 'png' port to a superior version that install the library 'libpng.so.6' BUUUTTTT 'gtk' will not be upgraded, so it will still depending on 'libpng.so.5' .. so here is my question: there is a way to avoid this?????? i means that 'gtk' load 'libpng.so' (that is a symbolic link to 'libpng.so.6') instead of 'libpng.so.5' at runtime i think this is a VERY VERY strict rule because in linux programs load 'lib*.so' instead 'lib*.so.#' except if that program was linked to 'lib*.so.#' at compilation time _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
hello tom we should keep in mind that new versions of libraries are built with previous versions compatibility in order to avoid 'crashing' .. i put the 'gtk' example because i upgrade my system yesterday and I got that situation .. I started to imagine what could happen if I restart 'gdm' at that moment .. and I think that 'gdm' will not start because 'gtk' will not find 'libpng.so.5' .. so I do the following: create a symbolic link: 'libpng.so.5' -> 'libpng.so.6' .. restart 'gdm' and all was fine what do you think about that ps: clic in 'reply to all' in order to reply to 'freebsd-hacker' list too, please (thanks) _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
I want to share one thing: I restarted my box right now (since I upgraded my box I haven't restarted) and I saw one interesting thing: - before upgrade GIMP was able to load PNG files - after upgrade GIMP can't load PNG files - when I did the symbolic link GIMP was able to load PNG files ONCE AGAIN - I delete the symbolic link, then restarted my box AAANNNDDDD GIMP is able to load PNG files ONCE AGAIN there is happening something that I don't know yet???? somebody knows???? _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
On Wed, Apr 14, 2010 at 12:42 PM, Gary Jennejohn hello and thanks gary .. I forgot 'libmap.conf' .. that could be a nice solution _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
On Wed, 14 Apr 2010 12:23:16 -0400 You might be able to do this with /etc/libmap.conf. See the man page for libmap.conf(5). -- Gary Jennejohn _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
The whole reason for a library version bump is because the libraries are not compatible with each other, usually due to a function being removed or its argument list changing, or a structure changing size. Symlinking one version onto another version might work, but only if the application doesn't use any of the removed or changed functions. http://article.gmane.org/gmane.comp.graphics.png.devel/3283 It's much safer to just leave the libraries alone. Just because you upgraded libpng doesn't mean that your old gtk binary will stop working (assuming you are using "portupgrade" or "portmaster -w" which preserves old libraries of course). Anyway, the FreeBSD port maintainers usually bump the revision of dependant ports when a major library like libpng gets upgraded, no, the rule is the same in Linux. Programs load "lib*.so.#" there also: (dan@linuxbox) ~># ldd /usr/bin/rrdtool linux-vdso.so.1 => (0x00007fff4f9ff000) librrd.so.2 => /usr/lib64/librrd.so.2 (0x00007fa047716000) libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00007fa04759b000) libpng.so.3 => /usr/lib64/libpng.so.3 (0x00007fa04745f000) libz.so.1 => /lib64/libz.so.1 (0x00007fa04734b000) libart_lgpl_2.so.2 => /usr/lib64/libart_lgpl_2.so.2 (0x00007fa047234000) libm.so.6 => /lib64/libm.so.6 (0x00007fa0470df000) libc.so.6 => /lib64/libc.so.6 (0x00007fa046e9f000) /lib64/ld-linux-x86-64.so.2 (0x00007fa04785e000) -- Dan Nelson dnelson@allantgroup.com _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
as I said: almost all new versions of libraries (those that developer knows what he/she is doing) maintain functions that are compatible with previous versions functions .. that's why gtk continue (right I disagree .. I have a program that depends on 'libpng.so.5' .. I tried to execute it after upgrade 'png' and it don't started becase the system lacks 'libpng.so.5' I solved the situation RECOMPILING the program .. doing that the program linked against NEW 'libpng.so.6' and when I tried to execute mmm .. I think it's not true because I maintain a port and i'm VERY VERY restricted to update the port because I depends on a mentor that will ONLY update the port in fbsd svn tree if I sent to him the tinderbox log of the sucessfully build of the port .. so I have not much patience to do all this things so I update the port and do ALL task including constructing the package into tinderbox ONLY when a new version of the program is available .. and I think that exists a lot of ports maintainers that are in same situation do you agree with me that it's difficult to a port maintainer to update his/her port because of this restriction???? could be a good idea to plan and implement a system to allow fbsd ports maintainers to maintain easyly the own ports via web or mail ONCE a fbsd mentor have uploaded his/her port to fbsd svn _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
On Wed, Apr 14, 2010 at 11:18 AM, Leinier Cruz Salfran < The port maintainer doesn't *have to* update anything. When library ports go through a library bump like this, all the ports that depend on it get an automatic PORTREVISION bump. All the port maintainer has to do is double-check that the port compiles with the new version of the lib. Only if there are issues with that (which usually get picked up by the -exp runs on the ports cluster), then the port maintainer has to step in and fix things. 9 times out of 10, a port maintainer doesn't have to do anything with a port In several years of port maintainership, I've never had a need for anything like this. A new version of an app I maintain is released, I update the port locally, test it, submit a PR with the update, someone looks at it and sends back suggestions/issues, the port is fixed locally and patches re-submitted to the PR, and then the port is committed to the tree. Overall, not a long process. If you maintain enough ports for enough time, and generate enough committed PRs to annoy people enough, you get rewarded with a commit bit. :) -- Freddie Cash fjwcash@gmail.com _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
okey maybe i didn't understood the 'bump' means .. I must to thank you okey let me see if I understood you .. you mean that I create a 'ONE_PORT' to a specific program version and if one of the library on which the 'ONE_PORT' depends change to a major version, then the 'ports cluster' put add PORTREVISION to the 'ONE_PORT' and update the oohh .. thanks for the tip :) _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
On Wed, Apr 14, 2010 at 12:02 PM, Leinier Cruz Salfran < Correct. The PORTVERSION doesn't change. But PORTREVISION gets bumped up by 1. That way, when user's check for updates in the ports tree, via "pkg_version -vl '<'" or "portversion -v" or similar tools, then ONE_PORT will be listed as "update available" like so (not exact syntax, going from memory): one_port-1.0.0 <= needs update (port has one_port-1.0.0_1) The _1 part is PORTREVISION. It's used to say "the version hasn't changed, but something in the ports tree requires this to be re-installed or 'upgraded'". Maybe an OPTIONS line was added, or a dependent library version changed, or a build dependency changed, or a new RC script was added, or something like that. There's some good examples/explanations of PORTREVISION in the FreeBSD Porter's Handbook. -- Freddie Cash fjwcash@gmail.com _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
<About to get flamed, I know> Untrue. Portupgrade deletes the old version of the port by default. The PNG upgrade was a major PITA, because I installed one new port that thought it had to have it. I'm sure 98% of the ports I then had to upgrade would have still worked just fine even if rebuilt against the old libpng. I think the complaint here is that the port dependencies system frequently gives the impression/enforces the rule that new ports will depend on whatever the most current version of everything is in the ports tree at the time they were built, forcing sort of a perpetual upgrade cycle. IMHO this is probably due to naive port maintainers (such as myself) incorrectly pointing a port at libpng.5 instead of any libpng, or libpng >= 5. Once the ports tree is 'poisoned' in this fashion, there's really no going back. I'd sure vote for an audit of this behavior as a summer of code project. Long story short, anything that sounds fundamental gets bumped (png, jpeg, tcl, python, gtk, etc, etc), I just sit back and get ready to spend two or three days retrying portupgrade -akOf -mBATCH=yes until everything sticks. If you've got OO or KDE4 installed, you might just want to forget it and pkg_delete -f *, then start over. I'm sticking by bsd though. You don't even have the opportunity to run an automated tool to clean & build everything from source automatically on linux. I'm sure rpm & apt dependencies are even nastier. Steve _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
Are you sure you're talking about portupgrade? From the manpage:
-u
--uninstall-shlibs Do not preserve old shared libraries. By
default, portupgrade preserves shared libraries
on uninstallation for safety. See the
pkg_deinstall(1) manpage and check out the -P
option for details.
I've 400 MB of shared libs in /usr/local/lib/compat/pkg as proof that it
I don't think the porter's handbook mentions the DEPENDS_* comparison
operators at all, so unless you read (and understood) the
${deptype:L}-depends target in bsd.port.mk, you might not know it existed.
--
Dan Nelson
dnelson@allantgroup.com
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
Nevermind; it's there. http://www.freebsd.org/doc/en/books/porters-handbook/makefile-depend.html#AEN2246 -- Dan Nelson dnelson@allantgroup.com _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
On Thu, 22 Apr 2010 15:38:14 -0700 Setting FORCE_PKG_REGISTER in /etc/make.conf should mitigate such problems. I actually have both png-1.2.43 and png-1.4.1_1 installed and the old /usr/local/lib/libpng.so.5 is still there along with the new /usr/local/lib/libpng.so.6. -- Gary Jennejohn _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"