On 17.02.2012 17:05, Zhihao Yuan wrote:
On Fri, Feb 17, 2012 at 2:57 PM, Mikhail T.<mi+t...@aldan.algebra.com> wrote:
On 17.02.2012 14:24, Zhihao Yuan wrote:
I regard this as a wrong practice. Here is why:
1. The way you specify the version in LIB_DEPENDS has NO relation with
how the port link to the lib. The port can link to the major version
(pkg-config), or the .so, etc.
I'm sorry, I can not parse the above part. Perhaps, a live example is in
order.
LIB_DEPENDS= png.6: or =png: does not affect how the lib got linked.
It always links to the latest libpng the time you compile the port.
Yes, this is correct. But irrelevant, really -- this will remain true, whether
or not LIB_DEPENDS lines contain explicit library numbers.
2. One responsibility of the ports system is to protect the user from
suffering from running a software which links to a ABI incompatible,
hence, wrong shared library.
This is a made-up non-reason, sorry. The only way to get into an ABI
incompatibility is to have -- at the time of the port building --
header-files declarations from one version of a library and
implementation(s) from another. Avoiding such situations is out of the scope
of the ports-system and this discussion.
Again, try to come up with a real-life example of how my proposal would
break ABI for an actual user... You can not.
This only happens when a minor version of a library is not compatible
with another one. OK, that's out of the scope.
We have not used minor library versions since switch-over to ELF... I do not
understand, what you are talking about.
3. "Known to cause problem"? Can I infer ""you can predict the future"
from that?
Yes, you can. Well-knowing the past 15 or so years of the ports-system, I
can predict some aspects of the future. For example:
committers will continue to forget to update some of the umpteen instances
of LIB_DEPENDS=foo.X in various ports, when bumping up major version of foo.
committers will continue to mindlessly bump-up these umpteen instances --
without actually verifying, that the new version of foo is still acceptable
to all of those dependants.
My opinion is that, fails to build is not a big trouble, at least we
notified the through portsnap/pkg_version; The user surprisingly finds
that his software fails to run is a bigger trouble.
The existing practice does not protect against this "bigger trouble" either --
whenever port installing libfoo.so is updated, all of the ports LIB_DEPENDing on
foo.X are matter-of-factly updated to LIB_DEPEND on foo.(X+1). At best, these
updates are verified to continue to /build/ -- but they are never verified to
continue to /work/ -- although they usually do work, of course.
`cvs log' shows thousands of commit messages matching the pattern "chas.*bump"
(libvpx included, of course) -- I'd be surprised to learn, the usability test
was conducted in 1% of these cases...
port-building will remain unduly difficult because of the wide-spread
mindless (mis)use of the major shlib-number in LIB_DEPENDS. Consider the
following scenario (substitute any of "png", "jpeg", "xml", etc. for "foo"):
The updates to major libs always bind to a larger updates in the ports
tree. You have to upgrade all of the ports depend on them no matter
how you use LIB_DEPENDS.
No, I should not have to. I might prefer to, but I should not be forced to do
it. And what's a "major lib" anyway? Does x264 qualify? If I want to add vlc,
for example, do you want to /force/ me to rebuild mplayer as well -- because
x264 went from 137 to 171 since I last built it?
You build a shiny new machine -- with the desktop of your choice (KDE,
Gnome, Xfce - whatever) from ports. Hours of build-time interrupted by
occasional `config' screens...
A week later you update your ports tree -- which sees version-bump of
libfoo.
You try to add a foo-using program bar to your computer -- and fail, because
the bar-port now insists on the very latest version of libfoo. Not because
the maintainer of bar determined, that the earlier versions are bad --
simply because the maintainer of foo went through all dependents and updated
the LIB_DEPENDS lines in all of them, as is the current sad practice.
You now have to either portupgrade libfoo -- which means, your desktop will
be using libfoo.N and the newly-built bar will be using libfoo.N+1
(inefficient and sometimes a source of problems in its own), or go through
rebuilding all of the foo-using ports again...
I regards what you said above as the regular routine, and I can't see
how your practice can improve such a routine.
If the port bar is willing to compile against /any/ version of libfoo (and the
vast majority of ports are), then the problem I described will not strike anyone
-- bar will built against whatever libfoo is already installed on the building
computer, and that's it. The user still has an option to upgrade everything to
the latest, but he is no longer forced to do it just to add one more port to an
existing install. My proposal will also eliminate the outright build breakages
like the one, which started this thread.
So, to link to a version explicitly should be the default. Only a
library behaviors "good" in its development history can be considered
to use it's libname only in LIB_DEPENDS.
I'm not sure, what you mean by "link to a version". Once again, I beg you to
offer a live example. Yours,
I mean LIB_DEPENDS= png.6
So far, I've presented detailed examples of how the existing practice -- which
you defend -- breaks things for users and increases maintainers' chores. You
have not presented any disadvantages of switching to my proposal... I don't
think, there are any, do you?
-mi
_______________________________________________
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
