Re: there is a way to avoid strict libraries linking?
On Wed, Apr 14, 2010 at 12:32 PM, Tom Evans wrote: > On Wed, Apr 14, 2010 at 5:23 PM, Leinier Cruz Salfran > wrote: >> 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' BUUU '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 >> > > The reason the library version is bumped is to avoid loading > libpng.so.6 into a process looking for libpng.so.5. If you want to try > it, you can use /etc/libmap.conf to map requests for libpng.so.5 into > libpng.so.6 (and watch your apps crash instead of not running). > > > Tom > 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-unsubscr...@freebsd.org"
Re: there is a way to avoid strict libraries linking?
On Wed, Apr 14, 2010 at 12:42 PM, Gary Jennejohn wrote: > On Wed, 14 Apr 2010 12:23:16 -0400 > Leinier Cruz Salfran wrote: > >> 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' BUUU '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 >> > > You might be able to do this with /etc/libmap.conf. See the man page > for libmap.conf(5). > > -- > 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-unsubscr...@freebsd.org"
Re: there is a way to avoid strict libraries linking?
On Wed, 14 Apr 2010 12:23:16 -0400 Leinier Cruz Salfran wrote: > 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' BUUU '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 > 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-unsubscr...@freebsd.org"
Re: there is a way to avoid strict libraries linking?
In the last episode (Apr 14), Leinier Cruz Salfran said: > 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' BUUU '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 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, to force everyone to upgrade anything that depends on it. > 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 no, the rule is the same in Linux. Programs load "lib*.so.#" there also: (d...@linuxbox) ~># ldd /usr/bin/rrdtool linux-vdso.so.1 => (0x7fff4f9ff000) librrd.so.2 => /usr/lib64/librrd.so.2 (0x7fa047716000) libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x7fa04759b000) libpng.so.3 => /usr/lib64/libpng.so.3 (0x7fa04745f000) libz.so.1 => /lib64/libz.so.1 (0x7fa04734b000) libart_lgpl_2.so.2 => /usr/lib64/libart_lgpl_2.so.2 (0x7fa047234000) libm.so.6 => /lib64/libm.so.6 (0x7fa0470df000) libc.so.6 => /lib64/libc.so.6 (0x7fa046e9f000) /lib64/ld-linux-x86-64.so.2 (0x7fa04785e000) -- Dan Nelson dnel...@allantgroup.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: there is a way to avoid strict libraries linking?
On Wed, Apr 14, 2010 at 1:48 PM, Dan Nelson wrote: > In the last episode (Apr 14), Leinier Cruz Salfran said: >> 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' BUUU '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 > > 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 > 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 now) working on my box > It's much safer to just leave the libraries alone. agree > Just because you > upgraded libpng doesn't mean that your old gtk binary will stop working 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 it once again it works fine > Anyway, the FreeBSD port maintainers usually bump the > revision of dependant ports when a major library like libpng gets upgraded, > to force everyone to upgrade anything that depends on it. > 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 tree? >> 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 > > no, the rule is the same in Linux. Programs load "lib*.so.#" there also: > > (d...@linuxbox) ~># ldd /usr/bin/rrdtool > linux-vdso.so.1 => (0x7fff4f9ff000) > librrd.so.2 => /usr/lib64/librrd.so.2 (0x7fa047716000) > libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x7fa04759b000) > libpng.so.3 => /usr/lib64/libpng.so.3 (0x7fa04745f000) > libz.so.1 => /lib64/libz.so.1 (0x7fa04734b000) > libart_lgpl_2.so.2 => /usr/lib64/libart_lgpl_2.so.2 > (0x7fa047234000) > libm.so.6 => /lib64/libm.so.6 (0x7fa0470df000) > libc.so.6 => /lib64/libc.so.6 (0x7fa046e9f000) > /lib64/ld-linux-x86-64.so.2 (0x7fa04785e000) > > -- > Dan Nelson > dnel...@allantgroup.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: there is a way to avoid strict libraries linking?
On Wed, Apr 14, 2010 at 2:17 PM, Mike Meyer wrote: > On Wed, 14 Apr 2010 12:44:32 -0400 > Leinier Cruz Salfran wrote: > >> On Wed, Apr 14, 2010 at 12:32 PM, Tom Evans wrote: >> > On Wed, Apr 14, 2010 at 5:23 PM, Leinier Cruz Salfran >> > wrote: >> >> 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' BUUU '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 >> > >> > The reason the library version is bumped is to avoid loading >> > libpng.so.6 into a process looking for libpng.so.5. If you want to try >> > it, you can use /etc/libmap.conf to map requests for libpng.so.5 into >> > libpng.so.6 (and watch your apps crash instead of not running). >> >> we should keep in mind that new versions of libraries are built with >> previous versions compatibility in order to avoid 'crashing' > > That's a false generalization. While it may be true for most > libraries, it's definitely not true in all cases. you have right mike > Since I tend to do > upgrades wholesale, I only find the ones where the breakage is exposed > at the source level, so the last one I recall is when libgtkhtml > changed the underlying print engine, breaking anything that depended > on it for printing, like gnucash. > 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 AAANNN 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-unsubscr...@freebsd.org"
Re: there is a way to avoid strict libraries linking?
On Wed, Apr 14, 2010 at 11:18 AM, Leinier Cruz Salfran < salfrancl.lis...@gmail.com> wrote: > On Wed, Apr 14, 2010 at 1:48 PM, Dan Nelson > wrote:> Just because you > > Anyway, the FreeBSD port maintainers usually bump the > > revision of dependant ports when a major library like libpng gets > upgraded, > > to force everyone to upgrade anything that depends on it. > > > > 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 > 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 until a new version of the app is released. > 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 > tree > 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 fjwc...@gmail.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: there is a way to avoid strict libraries linking?
On Wed, Apr 14, 2010 at 2:50 PM, Freddie Cash wrote: > On Wed, Apr 14, 2010 at 11:18 AM, Leinier Cruz Salfran < > salfrancl.lis...@gmail.com> wrote: > >> On Wed, Apr 14, 2010 at 1:48 PM, Dan Nelson >> wrote:> Just because you >> > Anyway, the FreeBSD port maintainers usually bump the >> > revision of dependant ports when a major library like libpng gets >> upgraded, >> > to force everyone to upgrade anything that depends on it. >> > >> >> 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 >> > > 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. > okey maybe i didn't understood the 'bump' means .. I must to thank you because of comment about this subject > 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. > 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 *_DEPENDS automatically > 9 times out of 10, a port maintainer doesn't have to do anything with a port > until a new version of the app is released. > okey okey do not repeat again .. I read 9 times out of 10 ;) > >> 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 >> tree >> > > 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. :) > 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-unsubscr...@freebsd.org"
Re: there is a way to avoid strict libraries linking?
On Wed, Apr 14, 2010 at 12:02 PM, Leinier Cruz Salfran < salfrancl.lis...@gmail.com> wrote: > On Wed, Apr 14, 2010 at 2:50 PM, Freddie Cash wrote: > > 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. > > okey maybe i didn't understood the 'bump' means .. I must to thank you > because of comment about this subject > > > 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. > > 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 > *_DEPENDS automatically 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 fjwc...@gmail.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: there is a way to avoid strict libraries linking?
> 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 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-unsubscr...@freebsd.org"
Re: there is a way to avoid strict libraries linking?
In the last episode (Apr 22), Steve Franks said:
> > 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
>
> 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.
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
does this by default, too. I should probably clean that out someday :)
> 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.
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
dnel...@allantgroup.com
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: there is a way to avoid strict libraries linking?
In the last episode (Apr 22), Dan Nelson said:
> In the last episode (Apr 22), Steve Franks said:
> > (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.
>
> 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.
Nevermind; it's there.
http://www.freebsd.org/doc/en/books/porters-handbook/makefile-depend.html#AEN2246
--
Dan Nelson
dnel...@allantgroup.com
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: there is a way to avoid strict libraries linking?
On Thu, 22 Apr 2010 15:38:14 -0700 Steve Franks wrote: > > 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 > > 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. > 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-unsubscr...@freebsd.org"
