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
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
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
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
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
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
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
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
2012/2/17 Doug Barton do...@freebsd.org:
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
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
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:
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
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
Quoting Alex Dupre a...@freebsd.org (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
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
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
on 17/02/2012 13:04 Olivier Smedts said the following:
2012/2/17 Doug Barton do...@freebsd.org:
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
2012/2/17 Andriy Gapon a...@freebsd.org:
on 17/02/2012 13:04 Olivier Smedts said the following:
2012/2/17 Doug Barton do...@freebsd.org:
On 02/17/2012 02:14, Andriy Gapon wrote:
Speaking about FreeBSD ports' current way of recording dependencies and
overzealous portrevision bumping.
We're
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
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
On 17 February 2012 13:59, Mikhail T. mi+t...@aldan.algebra.com 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.
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
On Fri, Feb 17, 2012 at 7:59 AM, Mikhail T. mi+t...@aldan.algebra.com 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.
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
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
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
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
On Feb 17, 2012 5:17 PM, Mikhail T. mi+t...@aldan.algebra.com wrote:
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
On Feb 17, 2012 5:41 PM, Mikhail T. mi+t...@aldan.algebra.com 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,
29 matches
Mail list logo
