cvs commit: ports/devel/adime Makefile ports/x11-wm/icewm Makefile ports/graphics/scr2png Makefile ports/x11/xbindkeys Makefile

[Alexey Dokuchaev]

On Sun, Feb 19, 2012 at 05:37:41PM -0800, Doug Barton wrote:
> On 02/19/2012 17:23, Alexey Dokuchaev wrote:
> > "Wine argument"
> 
> I think you meant "Whine" :)

;-))

> 1. The vast majority of the time dependent ports work with any version
> of the library. Therefore over-specifying the version numbers creates
> useless churn in the CVS repo, and can cause users to needlessly
> recompile things that are already working just fine.

By design, shlib bump indicates ABI changes.  Version number is recorded
within the executable.  Users would be able to continue using their things
after dependency update with shlib version change only as long as they have
old library preserved in /usr/local/lib/compat/pkg.  For existing packages,
shlib version is always recorded regardless of if it's specified in
LIB_DEPENDS or not.

> 2. In those cases where we know that a thing needs at least a certain
> version of a lib, it should be specified with >=, and then left alone.

What if next version will break it?  How can we be sure about the "at least"
part?

> Your argument seems to boil down to, "Since we can't be sure, always
> specify, and always bump."

Right.  When dependent ABI changes, consumers must be recompiled.  Exact
version in LIB_DEPENDS lines is not strictly required, but helps to keep
track.  It's orthogonal to PORTREVISION.

> My counterargument is that doing what you suggest defeats the whole
> purpose of shared libs in the first place.
> 
> Imagine the following scenario:
> 1. User installs a system, including various ports, including libfoo.so.1
> 2. User does not upgrade system for $N $time_periods.
> 3. libfoo is updated and the current version of the shared lib is
> libfoo.so.2
> 3. User wants shiny new port binbar. binbar works just fine with either
> version of libfoo, so after updating the ports tree the user now
> attempts to install binbar. What should happen?
> 
> IMO if the libfoo dependency is properly specified the user should be
> able to make/install binbar without having to upgrade libfoo (barring
> security issues of course).

OK, I see.  That's true, I might want to have newest version of the app, but
older (stable) version of the dependency.  (In fact, I often do!  And it's a
bit annoying sometimes that portupgrade(8) does not let me to update a port
unless I previously agreed to update its dependencies as well.)

That said, the problem is not about recompiling existing installed ports
when dependency shlib version bumps.  It's about upgrading and building new
ports against previous (or any) dependency versions without having to hack
on LIB_DEPENDS manually.  I must admit I do not see how it can be addressed
other than removing explicit shlib version number in this case.

> Now, is that technical enough for you? :)

Yes, it is, thank you.

./danfe