Date: Tue, 12 Mar 2002 12:53:42 -0500 (EST) From: Mikhail Teterin <mi@aldan.algebra.com> To: knu@iDaemons.org Cc: roam@ringlet.net, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: ports/graphics/autotrace Makefile ports/graphics/graphviz Makefile ports/graphics/libafterimage Makefile ports/graphics/librsvg Makefile ports/graphics/libwmf Makefile ports/graphics/sdl_ttf Makefile ports/print/ft2demos Makefile ... Message-ID: <200203121753.g2CHrg3b074070@aldan.algebra.com> In-Reply-To: <86wuwhag96.wl@archon.local.idaemons.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 13 Mar, Akinori MUSHA wrote: >> All those ports will build with ANY freetype, and handling the binary >> upgrades is not the ports system's primary objective. Hardly even >> secondary. > I don't particularly object to your chagens by now, but I cannot fully > agree with that. Handling upgrades is not a priority, but making > ports-current work with older installation is not a priority either. I disagree. Here is my view. Ports System is all about building and installing third party software from its source code (when available). Some of that third party software depends on data-files, executables, and shared libraries, which are installed by other third (fourth?) party software. There needs to be a way of describing such dependencies. This descriptions are part of the _primary_ objective of the ports system. And any problems with them, and solutions to those problems are also parts of the _primary_ objective. The binary packages are derivatives of the ports and thus are of secondary importance. > I think people want to upgrade packages just as they want to build > ports with older libraries. It's hard to decide which should come > first, but as long as they don't conflict, let each of us do the best. The difference is, without my changes it is NOT POSSIBLE to build a port using an older library. However, the binary upgrades can still happen after my changes. Especially when you implement the feature discussed at the bottom. :-) >> in promptly -- you are yet to convince me they are wrong. Yours, > > In the last discussion, some people expressed anxiety that people > might neglect bumping PORTREVISIONs because of your changes. Do you > remember? I do. However, I countered, that such bumping is only serving the binary upgrades, which can be done without it anyway, and rejected that argument. >> > Or users may just get lost. >> >> This means the upgrade mechanism is incomplete. If portupgrade (or >> whatever tool is used) upgrades port A, which results in a shared >> library bump of libA, it should automaticly upgrade all ports B, C, D >> which LIB_DEPEND on libA -- without an explicit PORTREVISION bump in >> B, C, and D. > > Oh, thanks for the hint. :) > > I'll add the feature to portupgrae in the future, although it's not > very easy to implement. I find it much easier to communicate with computers, than with people :-) If I knew Python, I'd concentrate on coding the feature instead of preaching to people... Then, the PORTREVISION bump would only be needed if the port itself changes. -mi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200203121753.g2CHrg3b074070>