Re: recent portrevision bump for libvpx
On 02/17/2012 02:14, Andriy Gapon wrote: > Speaking about FreeBSD ports' current way of recording dependencies and > overzealous portrevision bumping. We're way to aggressive about recording grandchild dependencies. Repeated calls for this to be addressed have been ignored. Meanwhile you can put EXPLICIT_PACKAGE_DEPENDS= true in make.conf which helps quite a bit for keeping your local /var/db/pkg tidy. 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/ ___ 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"
Re: recent portrevision bump for libvpx
Andriy Gapon wrote:
Needless to say that all these ports got their port revisions bumped.
Was there a good reason for that? I don't know.
I just know that now I need to needlessly reinstall/rebuild about a hundred
ports, many of which are not quite light-weight.
It's time to experiment seriously with ${EXPLICIT_PACKAGE_DEPENDS} and
libtool patch to not link to indirect dependencies (ports/104877).
Ideally a port should include in LIB_DEPENDS all the direct dependencies.
--
Alex Dupre
___
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"
Re: recent portrevision bump for libvpx
Alex Dupre wrote: Ideally a port should include in LIB_DEPENDS all the direct dependencies. And consequentially it should be bumped *only if* a direct dependency has a library version bump. With the current "link to all" attitude, we are never sure what need to be bumped, because of hidden dependencies, and so "portmaster -r" and similar approaches are always recommended in addition to probabilistic portrevision bumps. -- Alex Dupre ___ 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"
Re: recent portrevision bump for libvpx
on 17/02/2012 12:23 Doug Barton said the following: > Meanwhile you can put EXPLICIT_PACKAGE_DEPENDS= true in make.conf which > helps quite a bit for keeping your local /var/db/pkg tidy. Thank you for this good advice! Unfortunately, it can't help with the gratuitous revision bumps, but it should improve e.g. portmaster -r. -- Andriy Gapon ___ 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"
Re: recent portrevision bump for libvpx
2012/2/17 Doug Barton : > On 02/17/2012 02:14, Andriy Gapon wrote: >> Speaking about FreeBSD ports' current way of recording dependencies and >> overzealous portrevision bumping. > > We're way to aggressive about recording grandchild dependencies. > Repeated calls for this to be addressed have been ignored. > > Meanwhile you can put EXPLICIT_PACKAGE_DEPENDS= true in make.conf which > helps quite a bit for keeping your local /var/db/pkg tidy. For me (526 ports installed, KDE4 and a long time EXPLICIT_PACKAGE_DEPENDS user), I only had to portmaster libvpx and ffmpeg. # cat /var/db/pkg/libvpx-1.0.0/+REQUIRED_BY ffmpeg-0.7.11_3,1 pkg_libchk reports nothing else needing libvpx... -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." ___ 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"
Re: recent portrevision bump for libvpx
Alexander Leidinger wrote: When I made the EXPLICIT_PACKAGE_DEPENDS patch, I noticed that there is not only libtool at fault (reaction of the libtool developers was IIRC: it's not trivial to fix known problems for the cross-building case (for libtool-1.x?)), but also pkg-config and similar things Yes, I know, it's correct what you say, but this doesn't prevent to improve things. I'm not saying that tomorrow we'll have a perfect ports tree where all and only direct dependencies will be listed, but if we don't even start... Currently we have exactly the opposite case: ports that have direct (maybe not needed) dependencies to libraries that are not recorded in Makefiles. This is the root cause of "portmaster -r" or aggressive bumps. -- Alex Dupre ___ 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"
Re: recent portrevision bump for libvpx
Speaking of recent libvpx update, some ports explicitly look for libvpx.so.0, and fail to update trying to install again libvpx which is already installed. e.g. multimedia/gstreamer-plugins-vp8 -- View this message in context: http://freebsd.1045724.n5.nabble.com/recent-portrevision-bump-for-libvpx-tp5492060p5492205.html Sent from the freebsd-ports mailing list archive at Nabble.com. ___ 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"
Re: recent portrevision bump for libvpx
On Fri, 17 Feb 2012 02:23:24 -0800 Doug Barton articulated: > Meanwhile you can put EXPLICIT_PACKAGE_DEPENDS= true in make.conf > which helps quite a bit for keeping your local /var/db/pkg tidy. Where is that knob documented? I have not come across it before. Is it localized to "portmaster" or does it work with any package management program? -- Carmel ✌ carmel...@hotmail.com ___ 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"
Re: recent portrevision bump for libvpx
On 17/02/2012 10:38, Alex Dupre wrote: > Alex Dupre wrote: >> Ideally a port should include in LIB_DEPENDS all the direct dependencies. > > And consequentially it should be bumped *only if* a direct dependency > has a library version bump. With the current "link to all" attitude, we > are never sure what need to be bumped, because of hidden dependencies, > and so "portmaster -r" and similar approaches are always recommended in > addition to probabilistic portrevision bumps. > You could record all the shared libraries used by a port as comments in the +CONTENTS list when it is packaged. Adding code to run ldd(1) against the files installed by the port and processing the results shouldn't be too hard. Then portmaster(8) et al could have a way of telling precisely what needed to be rebuilt for this sort of shlib version bump. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: recent portrevision bump for libvpx
Quoting Alex Dupre (from Fri, 17 Feb 2012 11:33:17 +0100):
Andriy Gapon wrote:
Needless to say that all these ports got their port revisions bumped.
Was there a good reason for that? I don't know.
I just know that now I need to needlessly reinstall/rebuild about a hundred
ports, many of which are not quite light-weight.
It's time to experiment seriously with ${EXPLICIT_PACKAGE_DEPENDS}
and libtool patch to not link to indirect dependencies
(ports/104877). Ideally a port should include in LIB_DEPENDS all the
direct dependencies.
When I made the EXPLICIT_PACKAGE_DEPENDS patch, I noticed that there
is not only libtool at fault (reaction of the libtool developers was
IIRC: it's not trivial to fix known problems for the cross-building
case (for libtool-1.x?)), but also pkg-config and similar things
(dependencies of dependencies where specified, e.g. your port links
against liba, the pkg-config for liba also told to link against libb
which liba depends upon but for which the ABI was not exposed to your
port by liba, but this caused a record of libb to show up in binaries
of your port). I do not know if the situation improved in _all_ ports,
but some look more sane.
You can also have a look at
/usr/ports/Tools/scripts/explicit_lib_depends.sh, thats a script which
analyzes the recorded dependencies in binaries for a given port (this
may be different from what is recorded in LIB_DEPENDS, and it can be
different from it even if LIB_DEPENDS is 100% correct). So if a lib
which is listed in the output changes the soversion, you _have_ to
recompile this port, no matter if the binary has his hands in the ABI
of the changed lib or not (that's the port->liba->libb case from the
paragraph above).
Bye,
Alexander.
--
There must be at least 500,000,000 rats in the United
States; of course, I never heard the story before.
http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
___
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"
Re: recent portrevision bump for libvpx
Matthew Seaman wrote: Adding code to run ldd(1) against the files installed by the port and processing the results shouldn't be too hard. This could be an idea for ports maintainers, to verify if LIB_DEPENDS is set correctly, but cannot be used as its generic replacement. -- Alex Dupre ___ 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"
Re: recent portrevision bump for libvpx
On 17/02/2012 13:05, Alex Dupre wrote: > Matthew Seaman wrote: >> Adding code to run ldd(1) >> against the files installed by the port and processing the results >> shouldn't be too hard. > > This could be an idea for ports maintainers, to verify if LIB_DEPENDS is > set correctly, but cannot be used as its generic replacement. Quite so, but that's not the principal benefit. It's a way of efficiently answering the question "which of my installed ports need to be re-built as a result of this shlib change?" For the end users primarily. Having this data recorded in /var/db/pkg/foo-9.99/+CONTENTS makes answering that question something like: grep -l '@comment SHLIB:libwhatever' /var/db/pkg/*/+CONTENTS | \ cut -d '/' -f 5 Ideally a ports management tool would notice if any port updated a shlib to a different ABI version and suggest to the user which ports to rebuild. I assume something similar could be done for the new pkg tools, but I really have no idea how hard that would be. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: recent portrevision bump for libvpx
2012/2/17 Carmel : > On Fri, 17 Feb 2012 02:23:24 -0800 > Doug Barton articulated: > >> Meanwhile you can put EXPLICIT_PACKAGE_DEPENDS= true in make.conf >> which helps quite a bit for keeping your local /var/db/pkg tidy. > > Where is that knob documented? I have not come across it before. Is it > localized to "portmaster" or does it work with any package management > program? Nowhere I can think of... I've been using this since years because someone mentioned it on this mailing list :) And it's in ports/Mk/bsd.port.mk. Not specific to portmaster, but to the ports in general (when they register dependencies in /var/db/pkg/*/+REQUIRED_BY). -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." ___ 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"
Re: recent portrevision bump for libvpx
Quoting Alex Dupre (from Fri, 17 Feb 2012 12:08:39 +0100): Alexander Leidinger wrote: When I made the EXPLICIT_PACKAGE_DEPENDS patch, I noticed that there is not only libtool at fault (reaction of the libtool developers was IIRC: it's not trivial to fix known problems for the cross-building case (for libtool-1.x?)), but also pkg-config and similar things Yes, I know, it's correct what you say, but this doesn't prevent to improve things. I'm not saying that tomorrow we'll have a perfect I didn't tell it to prevent things. Just to make sure everyone knows the state of afairs. ports tree where all and only direct dependencies will be listed, but if we don't even start... Currently we have exactly the opposite case: ports that have direct (maybe not needed) dependencies to libraries that are not recorded in Makefiles. This is the root cause of "portmaster -r" or aggressive bumps. It could be an option to call the script in each tinderbox build and verify the result with what is available in LIB_DEPENDS. This would require extending the script with recent additions to USE_GNOME, USE_X11, ... Bye, Alexander. -- BOFH excuse #383: Your processor has taken a ride to Heaven's Gate on the UFO behind Hale-Bopp's comet http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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"
Re: recent portrevision bump for libvpx
on 17/02/2012 13:04 Olivier Smedts said the following: > 2012/2/17 Doug Barton : >> On 02/17/2012 02:14, Andriy Gapon wrote: >>> Speaking about FreeBSD ports' current way of recording dependencies and >>> overzealous portrevision bumping. >> >> We're way to aggressive about recording grandchild dependencies. >> Repeated calls for this to be addressed have been ignored. >> >> Meanwhile you can put EXPLICIT_PACKAGE_DEPENDS= true in make.conf which >> helps quite a bit for keeping your local /var/db/pkg tidy. > > For me (526 ports installed, KDE4 and a long time > EXPLICIT_PACKAGE_DEPENDS user), I only had to portmaster libvpx and > ffmpeg. I assume you report what you had to do before all the revisions were bumped? > # cat /var/db/pkg/libvpx-1.0.0/+REQUIRED_BY > ffmpeg-0.7.11_3,1 > > pkg_libchk reports nothing else needing libvpx... > -- Andriy Gapon ___ 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"
Re: recent portrevision bump for libvpx
2012/2/17 Andriy Gapon : > on 17/02/2012 13:04 Olivier Smedts said the following: >> 2012/2/17 Doug Barton : >>> On 02/17/2012 02:14, Andriy Gapon wrote: Speaking about FreeBSD ports' current way of recording dependencies and overzealous portrevision bumping. >>> >>> We're way to aggressive about recording grandchild dependencies. >>> Repeated calls for this to be addressed have been ignored. >>> >>> Meanwhile you can put EXPLICIT_PACKAGE_DEPENDS= true in make.conf which >>> helps quite a bit for keeping your local /var/db/pkg tidy. >> >> For me (526 ports installed, KDE4 and a long time >> EXPLICIT_PACKAGE_DEPENDS user), I only had to portmaster libvpx and >> ffmpeg. > > I assume you report what you had to do before all the revisions were bumped? I report what I had to do to have a working system, with working software and an up-to-date libvpx. I didn't update all the ports that were bumped (54 for me, and they're all quite big, mostly kde-related). But now I can't "portmaster -a" if I don't want to clog my computer for hours... and all those bumps are useless in my case, pkg_libchk confirms that nothing on my system was using libvpx except ffmpeg. >> # cat /var/db/pkg/libvpx-1.0.0/+REQUIRED_BY >> ffmpeg-0.7.11_3,1 >> >> pkg_libchk reports nothing else needing libvpx... >> -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." ___ 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"
Re: recent portrevision bump for libvpx
on 17/02/2012 18:02 Olivier Smedts said the following: > I report what I had to do to have a working system, with working > software and an up-to-date libvpx. I didn't update all the ports that > were bumped (54 for me, and they're all quite big, mostly > kde-related). But now I can't "portmaster -a" if I don't want to clog > my computer for hours... and all those bumps are useless in my case, > pkg_libchk confirms that nothing on my system was using libvpx except > ffmpeg. Right. So we are on the same page. -- Andriy Gapon ___ 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"
Re: recent portrevision bump for libvpx
On 17.02.2012 12:36, Chris Rees wrote: Yet again I'd like to point out, that -- contrary to the wide-spread > practice -- ports should not, by default, list a particular shlib major > number in LIB_DEPENDS. Only in cases, when a wrong version of some libfoo is > known to cause problems, should the correct version be explicitly given in > LIB_DEPENDS. Perhaps someone could make a patch for the Porter's Handbook. Last time I broached the subject, I could not get my argument through... I even once made a patch, which would've allowed the user (at their own risk) to tell bsd.port.mk to ignore all explicitly-specified shlib-major numbers -- and portmgr@ shut it down, even though the new flag would not be on by default. If the consensus has changed over the years, coming up with the new text for the manual would not be a problem... -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"
Re: recent portrevision bump for libvpx
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. 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. 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. * 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"): 1. 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... 2. A week later you update your ports tree -- which sees version-bump of libfoo. 3. 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. 4. 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... 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, -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"
Re: recent portrevision bump for libvpx
On Fri, Feb 17, 2012 at 2:57 PM, Mikhail T. 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. > > 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. > > 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. > 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. > > 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. > > 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 > > -mi -- Zhihao Yuan, nickname lichray The best way to predict the future is to invent it. ___ 4BSD -- http://4bsd.biz/ ___ 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"
Re: recent portrevision bump for libvpx
On 17.02.2012 17:05, Zhihao Yuan wrote: On Fri, Feb 17, 2012 at 2:57 PM, Mikhail T. 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 al
Re: recent portrevision bump for libvpx
On Feb 17, 2012 5:17 PM, "Mikhail T." wrote: > > On 17.02.2012 17:05, Zhihao Yuan wrote: >> >> On Fri, Feb 17, 2012 at 2:57 PM, Mikhail T. 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 proble
Re: recent portrevision bump for libvpx
On 17/02/2012 14:36, Matthew Seaman wrote: > On 17/02/2012 13:05, Alex Dupre wrote: >> Matthew Seaman wrote: >>> Adding code to run ldd(1) >>> against the files installed by the port and processing the results >>> shouldn't be too hard. >> >> This could be an idea for ports maintainers, to verify if LIB_DEPENDS is >> set correctly, but cannot be used as its generic replacement. > > Quite so, but that's not the principal benefit. It's a way of > efficiently answering the question "which of my installed ports need to > be re-built as a result of this shlib change?" For the end users > primarily. Having this data recorded in /var/db/pkg/foo-9.99/+CONTENTS > makes answering that question something like: > > grep -l '@comment SHLIB:libwhatever' /var/db/pkg/*/+CONTENTS | \ > cut -d '/' -f 5 > > Ideally a ports management tool would notice if any port updated a shlib > to a different ABI version and suggest to the user which ports to rebuild. > > I assume something similar could be done for the new pkg tools, but I > really have no idea how hard that would be. Sorry about the delay, but I've finally got down to coding up my idea. Apart from finding out that ldd(1) reacts quite badly to linux executables (there's a patch for that problem in PR bin/127276) it all seemed to work quite merrily. Comments / criticism gratefully accepted. The result is to add lines like so to the end of the +CONTENTS file (this is from xterm-278): [...] @comment @unexec /usr/local/bin/update-desktop-database > /dev/null || /usr/bin/true @comment SHLIB:libICE.so.6 @comment SHLIB:libSM.so.6 @comment SHLIB:libX11.so.6 @comment SHLIB:libXau.so.6 @comment SHLIB:libXaw7.so.7 @comment SHLIB:libXdmcp.so.6 @comment SHLIB:libXext.so.6 @comment SHLIB:libXft.so.2 @comment SHLIB:libXmu.so.6 @comment SHLIB:libXpm.so.4 @comment SHLIB:libXrender.so.1 @comment SHLIB:libXt.so.6 @comment SHLIB:libbz2.so.4 @comment SHLIB:libc.so.7 @comment SHLIB:libexpat.so.6 @comment SHLIB:libfontconfig.so.1 @comment SHLIB:libfreetype.so.9 @comment SHLIB:libncurses.so.8 @comment SHLIB:libpcre.so.1 @comment SHLIB:libpcreposix.so.0 @comment SHLIB:libpthread-stubs.so.0 @comment SHLIB:librpcsvc.so.5 @comment SHLIB:libutempter.so.0 @comment SHLIB:libxcb.so.2 @comment SHLIB:libz.so.5 @display +DISPLAY Having rebuilt everything on my system with this patch applied, and considering this notice in /usr/ports/UPDATING: 20120214: AFFECTS: users of devel/pcre AUTHOR: do...@freebsd.org Until all dependent ports have been updated you should update pcre in a manner that will preserve its old shared library. For example: # portmaster -w devel/pcre or # portupgrade devel/pcre I can now state with confidence that only the following ports would need to be rebuilt on my system: lucid-nonsense:/usr/ports:% grep -l '@comment SHLIB:libpcre.so' /var/db/pkg/*/+CONTENTS | cut -d '/' -f 5 apache-2.2.22_5 avahi-app-0.6.29_1 dbus-glib-0.94 gamin-0.1.10_4 gio-fam-backend-2.28.8_1 glib-2.28.8_4 gobject-introspection-0.10.8_1 libslang2-2.2.4_1 maildrop-2.5.5_1 nmap-5.61.t4_1 pcre-8.30_1 php5-5.3.10_1 xterm-278 This change seems to sit happily with the current pkg tools -- it survives pkg tarballs intact, and I haven't seen any problems in my testing. Of course, the time is utterly wonderful, given that the bright new age of pkgng is almost upon us. I'm still finding my way around the pkgng sources, but my initial impression is that something similar could be implemented without excessive difficulty. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW Index: bsd.port.mk === RCS file: /home/ncvs/ports/Mk/bsd.port.mk,v retrieving revision 1.706 diff -u -u -r1.706 bsd.port.mk --- bsd.port.mk 22 Feb 2012 17:34:47 - 1.706 +++ bsd.port.mk 27 Feb 2012 17:21:45 - @@ -4318,8 +4318,8 @@ install-desktop-entries install-license install-rc-script \ post-install post-install-script add-plist-info \ add-plist-docs add-plist-examples add-plist-data \ - add-plist-post fix-plist-sequence compress-man \ - install-ldconfig-file fake-pkg security-check + add-plist-post add-plist-shlibs fix-plist-sequence \ + compress-man install-ldconfig-file fake-pkg security-check _PACKAGE_DEP= install _PACKAGE_SEQ= package-message pre-package pre-package-script \ do-package post-package-script @@ -5859,6 +5859,29 @@ .endif .endif +.if !target(add-plist-shlibs) +add-plist-shlibs: +# Record all of the shared libraries used by
Re: Re: recent portrevision bump for libvpx
On -10.01.-28163 14:59, Jakub Lach wrote: Speaking of recent libvpx update, some ports explicitly look for libvpx.so.0, and fail to update trying to install again libvpx which is already installed. e.g. multimedia/gstreamer-plugins-vp8 Yet again I'd like to point out, that -- contrary to the wide-spread practice -- ports should not, by default, list a particular shlib major number in LIB_DEPENDS. Only in cases, when a wrong version of some libfoo is known to cause problems, should the correct version be explicitly given in LIB_DEPENDS. -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"
Re: Re: recent portrevision bump for libvpx
On 17 February 2012 13:59, Mikhail T. wrote: > On -10.01.-28163 14:59, Jakub Lach wrote: >> >> Speaking of recent libvpx update, some ports explicitly look >> for libvpx.so.0, and fail to update trying to install again libvpx >> which is already installed. >> >> e.g. multimedia/gstreamer-plugins-vp8 > > Yet again I'd like to point out, that -- contrary to the wide-spread > practice -- ports should not, by default, list a particular shlib major > number in LIB_DEPENDS. Only in cases, when a wrong version of some libfoo is > known to cause problems, should the correct version be explicitly given in > LIB_DEPENDS. Perhaps someone could make a patch for the Porter's Handbook. Chris ___ 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"
Re: Re: recent portrevision bump for libvpx
On Fri, Feb 17, 2012 at 7:59 AM, Mikhail T. wrote: > On -10.01.-28163 14:59, Jakub Lach wrote: >> >> Speaking of recent libvpx update, some ports explicitly look >> for libvpx.so.0, and fail to update trying to install again libvpx >> which is already installed. >> >> e.g. multimedia/gstreamer-plugins-vp8 > > Yet again I'd like to point out, that -- contrary to the wide-spread > practice -- ports should not, by default, list a particular shlib major > number in LIB_DEPENDS. Only in cases, when a wrong version of some libfoo is > known to cause problems, should the correct version be explicitly given in > LIB_DEPENDS. 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. 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. A software runs incorrectly is a disaster, and the shared library version is to prevent this, and the ports system is to protect the versioned shared libraries. Thus -- A port fails to find its depends better than it does not link, a software does not link is better than it does not run correctly. And your practice is trying to remove such protection. 3. "Known to cause problem"? Can I infer ""you can predict the future" from that? 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. > > -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" -- Zhihao Yuan, nickname lichray The best way to predict the future is to invent it. ___ 4BSD -- http://4bsd.biz/ ___ 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"
tinderbox question (Was: Re: recent portrevision bump for libvpx)
Alex Dupre wrote: And consequentially it should be bumped *only if* a direct dependency has a library version bump. This doesn't solve the fact that in 3 days my tinderbox has rebuilt nearly all ports 4 times. Is there a way to say tinderbox to not rebuild every ports (without portrevision bump) that depends on a just rebuilt port? -- Alex Dupre ___ 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"
Library numbers in LIB_DEPENDS considered harmful (Re: recent portrevision bump for libvpx)
On 17.02.2012 17:05, Zhihao Yuan wrote:
LIB_DEPENDS= png.6: or =png: does not affect how the lib got linked.
Allow me to rephrase my argument from a different perspective...
The language used in our ports' Makefiles is, largely, /declarative/ -- various
things are declared and then bsd.port.mk (and friends) interpret them to do the
right thing.
Each declaration is meant to say something, so let's examine, what a LIB_DEPENDS
entry declares:
LIB_DEPENDS=foo.V:${PORTSDIR}/cat/libfoo
The above line says, that this port needs a shared library libfoo.so.V to be
installed. It also says, how to install it, if it is not already present at
build-time.
If, in fact, the current port does not care, which version of libfoo is uses --
and most software does not -- then declaring an explicit V is wrong: it
/gratuitously/ tightens the build-time requirements. Unless a particular version
is, indeed, required, the above line should read simply:
LIB_DEPENDS=foo:${PORTSDIR}/cat/libfoo
Let's say, you sent someone to buy a bottle of dry red wine in a store. Wouldn't
you be (unpleasantly) surprised, if he returned empty-handed, because the store
did not have any Californian Pinot Noir of the 2003 vintage? Huh? You did not
ask for Pinot Noir. You did not specify the origin nor the year either -- why
did not he get something else that matched your much wider and easier-to-satisfy
requirement: "dry red wine"?
A similar thing happens here: if the, say, vlc software needs libx264 to be
available at build time, the FreeBSD port of vlc should not add a requirement of
a particular version to that.
-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"
Re: Library numbers in LIB_DEPENDS considered harmful (Re: recent portrevision bump for libvpx)
On 02/17/2012 15:41, Mikhail T. wrote:
> If, in fact, the current port does not care, which version of libfoo is
> uses -- and most software does not -- then declaring an explicit V is
> wrong: it /gratuitously/ tightens the build-time requirements. Unless a
> particular version is, indeed, required, the above line should read simply:
>
>LIB_DEPENDS=foo:${PORTSDIR}/cat/libfoo
Big +1. Same goes for how some of the build/run deps are specified. This
has definitely become a case of "If you give someone a knob, it's
overwhelmingly likely that they will twist it."
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/
___
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"
Re: Library numbers in LIB_DEPENDS considered harmful (Re: recent portrevision bump for libvpx)
On Feb 17, 2012 5:41 PM, "Mikhail T." wrote:
>
> On 17.02.2012 17:05, Zhihao Yuan wrote:
>>
>> LIB_DEPENDS= png.6: or =png: does not affect how the lib got linked.
>
> Allow me to rephrase my argument from a different perspective...
>
> The language used in our ports' Makefiles is, largely, declarative --
various things are declared and then bsd.port.mk (and friends) interpret
them to do the right thing.
>
> Each declaration is meant to say something, so let's examine, what a
LIB_DEPENDS entry declares:
>>
>> LIB_DEPENDS=foo.V:${PORTSDIR}/cat/libfoo
>
> The above line says, that this port needs a shared library libfoo.so.V to
be installed. It also says, how to install it, if it is not already present
at build-time.
>
> If, in fact, the current port does not care, which version of libfoo is
uses -- and most software does not -- then declaring an explicit V is
wrong: it gratuitously tightens the build-time requirements. Unless a
particular version is, indeed, required, the above line should read simply:
>>
>> LIB_DEPENDS=foo:${PORTSDIR}/cat/libfoo
>
> Let's say, you sent someone to buy a bottle of dry red wine in a store.
Wouldn't you be (unpleasantly) surprised, if he returned empty-handed,
because the store did not have any Californian Pinot Noir of the 2003
vintage? Huh? You did not ask for Pinot Noir. You did not specify the
origin nor the year either -- why did not he get something else that
matched your much wider and easier-to-satisfy requirement: "dry red wine"?
So what, I come to your bar and say "10 year red wine" in1998, you give me
a 1988 one. And I went your place again in 2008, and say "same wine", and
you give me a 1998 one?
>
> A similar thing happens here: if the, say, vlc software needs libx264 to
be available at build time, the FreeBSD port of vlc should not add a
requirement of a particular version to that.
>>
>> -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"
Re: Library numbers in LIB_DEPENDS considered harmful (Re: recent portrevision bump for libvpx)
On 18/02/2012 00:01, Doug Barton wrote:
> On 02/17/2012 15:41, Mikhail T. wrote:
>> If, in fact, the current port does not care, which version of libfoo is
>> uses -- and most software does not -- then declaring an explicit V is
>> wrong: it /gratuitously/ tightens the build-time requirements. Unless a
>> particular version is, indeed, required, the above line should read simply:
>>
>>LIB_DEPENDS=foo:${PORTSDIR}/cat/libfoo
>
> Big +1. Same goes for how some of the build/run deps are specified. This
> has definitely become a case of "If you give someone a knob, it's
> overwhelmingly likely that they will twist it."
How about the attached?
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil.
PGP: http://www.infracaninophile.co.uk/pgpkey
Index: src/portlint.pl
===
RCS file: /home/ncvs/ports/ports-mgmt/portlint/src/portlint.pl,v
retrieving revision 1.125
diff -u -u -r1.125 portlint.pl
--- src/portlint.pl 27 Dec 2011 01:26:34 - 1.125
+++ src/portlint.pl 18 Feb 2012 10:08:27 -
@@ -1330,6 +1330,13 @@
"found in
\${PORTSDIR}/Mk/bsd.apache.mk.");
}
+ # Check for over-specific shared library dependencies
+ if ( $j eq 'LIB_DEPENDS' && $m{'dep'} =~ m/(\.\d+$)/ ) {
+ &perror("WARN", $file, -1, "$j don't specify
the " .
+ "ABI version number $1 in $m{dep}
unless it is " .
+ "really necessary.");
+ }
+
# check port dir existence
$k = $m{'dir'};
$k =~ s/\${PORTSDIR}/$ENV{'PORTSDIR'}/;
signature.asc
Description: OpenPGP digital signature
Re: Library numbers in LIB_DEPENDS considered harmful (Re: recent portrevision bump for libvpx)
It's obviously a matter of trade-off, and I'm with Mikhail on this one, but in the end it all depends how well tested/maintained those ports would be. But it's not like that all ports upon bumping shlib version are tested now, are they? If not, then it's moot point. bes regards, - Jakub Lach -- View this message in context: http://freebsd.1045724.n5.nabble.com/recent-portrevision-bump-for-libvpx-tp5492060p5495053.html Sent from the freebsd-ports mailing list archive at Nabble.com. ___ 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"
