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

[Doug Barton]

On 02/19/2012 17:23, Alexey Dokuchaev wrote:
> "Wine argument"

I think you meant "Whine" :)

> does not sound too technical to me.  I asked a question, how
> can one guarantee if some arbitrary port is ABI dependent or not.  I have
> not heard the answer so far.  I myself do not see it either.  Thus, the
> whole point that specifying exact ABI version might not be required is moot.
> Thus, it's safer to always specify it.  At least it allows to catch versions
> inconsistencies earlier.

I think my arguments were clear, and technically oriented. To sum up:

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.
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.

Your argument seems to boil down to, "Since we can't be sure, always
specify, and always bump." 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 instals 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).

On workstation systems where we tend to just always update everything,
this is not much of an issue. But on servers and other long-lived
systems gratuitously updating libfoo can cause other things to break. I
don't think we should be doing that to our users unless we are certain
that it's necessary.


Now, is that technical enough for you? :)

Doug

-- 

	It's always a long day; 86400 doesn't fit into a short.

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/