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 seriou
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 de
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
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
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
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-li
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 do
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 su
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 whic
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 us
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
>
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 ca
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 dep
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 aggressi
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 -
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 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
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-
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
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 L
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 i
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 wid
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-v
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-plu
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 bu
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
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, require
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, declar
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. Unle
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
32 matches
Mail list logo