HI there, is anybody aware of any good reason why tdelibs14-trinity and some other packages have a very strict dependency on binutils in Debian Jessie and Wheezy (and I suspect also on previous versions and in Ubuntu, even though I didn't check)? For example I get dependencies such as: binutils (>= 2.23.52.20130828), binutils (<< 2.23.52.20130829).
The problem with such kind of dependency is that when binutils is updated, I need to do a full rebuild of TDE before I can update the binutils package on my machine. After the full rebuild is completed, everything can be updated, but I don't see the reason for having the '<<' part of the dependency since it doesn't seem to affect anything: TDE builds with both the old and the new binutils package.
So I am wondering if such strict dependency is intentional or if it is something that we are dragging along from the past (perhaps because of a broken or incompatible binutils version in the past).
If there isn't any particular reason, I will open a bug report in a few days about this point.
Thanks Michele
On Friday 18 of October 2013 17:23:21 Michele Calgaro wrote:
HI there, is anybody aware of any good reason why tdelibs14-trinity and some other packages have a very strict dependency on binutils in Debian Jessie and Wheezy (and I suspect also on previous versions and in Ubuntu, even though I didn't check)? For example I get dependencies such as: binutils (>= 2.23.52.20130828), binutils (<< 2.23.52.20130829).
The problem with such kind of dependency is that when binutils is updated, I need to do a full rebuild of TDE before I can update the binutils package on my machine. After the full rebuild is completed, everything can be updated, but I don't see the reason for having the '<<' part of the dependency since it doesn't seem to affect anything: TDE builds with both the old and the new binutils package.
So I am wondering if such strict dependency is intentional or if it is something that we are dragging along from the past (perhaps because of a broken or incompatible binutils version in the past).
If there isn't any particular reason, I will open a bug report in a few days about this point.
Thanks Michele
Hi Michele,
explanation of very tight depending on binutils is simple:
For easier detection of particular bug were incorporated into kdesktop_lock function to generate backtrace (commit 786e248c - tdebase). Later the same function incorporated into tdeio (commit a166b1da - tdelibs). And lastly, both these functions were replaced with improved function kdBacktrace in kdebug (commit a5ba7ad7 - tdelibs).
This implementation uses for generate backtraces library bfd from binutils. And this library is causing this problem with a very tight dependency. This library is always one specific version and does not allow even a small difference. For example on Debian Squeeze: libbfd-2.20.1-system.20100303.so
For this reason, wherever it is used kdBacktrace => is dependent on libbfd => is so strict dependency on a particular version of binutils.
The solution would be if instead of linking the library dynamically loaded. But it can be a problem when that will happen in a crash handler => in an emergency situation.
Hi Michele,
explanation of very tight depending on binutils is simple:
For easier detection of particular bug were incorporated into kdesktop_lock function to generate backtrace (commit 786e248c - tdebase). Later the same function incorporated into tdeio (commit a166b1da - tdelibs). And lastly, both these functions were replaced with improved function kdBacktrace in kdebug (commit a5ba7ad7 - tdelibs).
This implementation uses for generate backtraces library bfd from binutils. And this library is causing this problem with a very tight dependency. This library is always one specific version and does not allow even a small difference. For example on Debian Squeeze: libbfd-2.20.1-system.20100303.so
For this reason, wherever it is used kdBacktrace => is dependent on libbfd => is so strict dependency on a particular version of binutils.
The solution would be if instead of linking the library dynamically loaded. But it can be a problem when that will happen in a crash handler => in an emergency situation.
-- Slavek
Thanks Slavek, very clear! Cheers Michele
2013/10/21 Michele Calgaro michele.calgaro@yahoo.it
Hi Michele,
explanation of very tight depending on binutils is simple:
For easier detection of particular bug were incorporated into
kdesktop_lock
function to generate backtrace (commit 786e248c - tdebase). Later the
same
function incorporated into tdeio (commit a166b1da - tdelibs). And lastly, both these functions were replaced with improved function kdBacktrace in kdebug (commit a5ba7ad7 - tdelibs).
This implementation uses for generate backtraces library bfd from
binutils.
And this library is causing this problem with a very tight dependency.
This
library is always one specific version and does not allow even a small difference. For example on Debian Squeeze:
libbfd-2.20.1-system.20100303.so
For this reason, wherever it is used kdBacktrace => is dependent on
libbfd
=> is so strict dependency on a particular version of binutils.
The solution would be if instead of linking the library dynamically
loaded.
But it can be a problem when that will happen in a crash handler => in an emergency situation.
-- Slavek
Thanks Slavek, very clear! Cheers Michele
Slávek, AFAIR since commit a5ba7ad7 tdelibs supposed to be build without bfd support by default because backtrace is pretty readable even without it. May be the dependence in packages are obsolete for now?
On Tuesday 22 of October 2013 22:18:35 Fat-Zer wrote:
2013/10/21 Michele Calgaro michele.calgaro@yahoo.it
Hi Michele,
explanation of very tight depending on binutils is simple:
For easier detection of particular bug were incorporated into
kdesktop_lock
function to generate backtrace (commit 786e248c - tdebase). Later the
same
function incorporated into tdeio (commit a166b1da - tdelibs). And lastly, both these functions were replaced with improved function kdBacktrace in kdebug (commit a5ba7ad7 - tdelibs).
This implementation uses for generate backtraces library bfd from
binutils.
And this library is causing this problem with a very tight dependency.
This
library is always one specific version and does not allow even a small difference. For example on Debian Squeeze:
libbfd-2.20.1-system.20100303.so
For this reason, wherever it is used kdBacktrace => is dependent on
libbfd
=> is so strict dependency on a particular version of binutils.
The solution would be if instead of linking the library dynamically
loaded.
But it can be a problem when that will happen in a crash handler => in an emergency situation.
-- Slavek
Thanks Slavek, very clear! Cheers Michele
Slávek, AFAIR since commit a5ba7ad7 tdelibs supposed to be build without bfd support by default because backtrace is pretty readable even without it. May be the dependence in packages are obsolete for now?
Yes, by default it is off, but for Debian / Ubuntu packages is on. If the backtrace without bfd is good enough, we can for Debian / Ubuntu packages also turn off bfd. This would avoid such a strict dependence.
What is your opinion?
Slavek
Slávek, AFAIR since commit a5ba7ad7 tdelibs supposed to be build without
bfd support by default because backtrace is pretty readable even without it. May be the dependence in packages are obsolete for now?
Yes, by default it is off, but for Debian / Ubuntu packages is on. If the backtrace without bfd is good enough, we can for Debian / Ubuntu packages also turn off bfd. This would avoid such a strict dependence.
What is your opinion?
Slavek
Doing a full rebuild when binutils gets updated is not a huge problem after all, so we could keep the tight dependency if we really need it. On the other hand this could become an issue for users of Debian Stable (and Ubuntu I guess) who uses only official TDE releases and not the nightly builds. If there is an update for Stable, the users would be unable to update their binutils package until a new TDE release using the same binutils version is available.
Perhaps a savy solution would be to keep the dependency from bfd off by default, so the aforementioned users would have no problems if a Stable update becomes available. We can add a compile option to enable the bdf dependency, so if we need to debug some nasty bugs we can recompile everything and work with the enhanced backtrace information.
What do you think?
Michele
Dne st 23. října 2013 Michele Calgaro napsal(a):
Doing a full rebuild when binutils gets updated is not a huge problem after all, so we could keep the tight dependency if we really need it. On the other hand this could become an issue for users of Debian Stable (and Ubuntu I guess) who uses only official TDE releases and not the nightly builds. If there is an update for Stable, the users would be unable to update their binutils package until a new TDE release using the same binutils version is available.
Perhaps a savy solution would be to keep the dependency from bfd off by default, so the aforementioned users would have no problems if a Stable update becomes available. We can add a compile option to enable the bdf dependency, so if we need to debug some nasty bugs we can recompile everything and work with the enhanced backtrace information.
What do you think?
I believe that a close relationship to binutils is just a minor problem for users running stable version. It is very unlikely that in the updates for stable version of Debian/Ubuntu distribution (or backports) will be updated binutils, which would break dependencies.
The problem is therefore only applies to users who use testing and unstable distributions. For such versions of distributions is not possible to release the "final" versions of TDE, because any time something can go wrong. I assume that users will always have to use either nightly-builds or preliminary updates for stable TDE branch. As was my ppa for v3.5.13.x branch.
In any case, if backtraces is good even without the lib bfd, we can turn off WITH_LIBBFD and remove binutils-dev from tdelibs-trinity build-deps and tdelibs14-trinity-dev dependencies. To me this seems appropriate.
Slavek --
I believe that a close relationship to binutils is just a minor problem for users running stable version. It is very unlikely that in the updates for stable version of Debian/Ubuntu distribution (or backports) will be updated binutils, which would break dependencies.
The problem is therefore only applies to users who use testing and unstable distributions. For such versions of distributions is not possible to release the "final" versions of TDE, because any time something can go wrong. I assume that users will always have to use either nightly-builds or preliminary updates for stable TDE branch. As was my ppa for v3.5.13.x branch.
I any case, if backtraces is good even without the lib bfd, we can turn off WITH_LIBBFD and remove binutils- dev from tdelibs-trinity build-deps and tdelibs14-trinity-dev dependencies. To me this seems appropriate.
Slavek
You have more experience than me, so I leave the choice to you and Tim. Both choices are ok for me. I usually do a full rebuild every month or two, so in the worst case I just hold up the binutils update for a few weeks.
Michele
On Thursday 24 of October 2013 03:07:15 Michele Calgaro wrote:
I believe that a close relationship to binutils is just a minor problem for users running stable version. It is very unlikely that in the updates for stable version of Debian/Ubuntu distribution (or backports) will be updated binutils, which would break dependencies.
The problem is therefore only applies to users who use testing and unstable distributions. For such versions of distributions is not possible to release the "final" versions of TDE, because any time something can go wrong. I assume that users will always have to use either nightly-builds or preliminary updates for stable TDE branch. As was my ppa for v3.5.13.x branch.
I any case, if backtraces is good even without the lib bfd, we can turn off WITH_LIBBFD and remove binutils- dev from tdelibs-trinity build-deps and tdelibs14-trinity-dev dependencies. To me this seems appropriate.
Slavek
You have more experience than me, so I leave the choice to you and Tim. Both choices are ok for me. I usually do a full rebuild every month or two, so in the worst case I just hold up the binutils update for a few weeks.
Michele
Right now I push into tde-packaging commit 499de1ac: Disable WITH_LIBBFD in tdelibs on Debian and Ubuntu. We can look forward to cancel the tight dependency on binutils from the next tdelibs rebuild :)
Slavek
You have more experience than me, so I leave the choice to you and Tim. Both choices are ok for me. I usually do a full rebuild every month or two, so in the worst case I just hold up the binutils update for a few weeks.
Michele
Right now I push into tde-packaging commit 499de1ac: Disable WITH_LIBBFD in tdelibs on Debian and Ubuntu. We >can look forward to cancel the tight dependency on binutils from the next tdelibs rebuild :)
Slavek
Sounds great! Thanks.
Michele
-
Fat-Zer -
Michele Calgaro -
Slávek Banko